<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
        "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
    <meta name="viewport"
          content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">
    <link href="../Styles/base.css" rel="stylesheet" type="text/css"/>
</head>

<body>
<p>About Face 4 : 交互设 it 箱髓</p>

<p>最后的产品。</p>

<p><span id="filepos0000731370"></span></p>

<p><font size="6">验证与测试设计</font></p>

<p>在交互设计项目过程中，除了人物模型和验证场景之外，还要在真实的使用者面前验证方 案，看看到底效果如何。一旦解决方案足够细致，就可以向用户展现一些具体的内容，从而获 得用户反馈。即便发现设计需要进一步修改，也仍有足够的时间操作。</p>

<p>根据我们以往的经验，用户反馈和可用性测试对于发现交互框架中的主要问题及某些方面 的细化，比如按钮标签、操作顺序和优先级等，是很有帮助的。并且对于有些操作的微调也很
    有好处，比如拨动一个硬件的按钮时屏幕滚动的快慢响应等。不过，要想进行超出首次使用时 的易学性的全方位评估，还很困难。对于针对中级和专家级用户的产品可用性评估的确有一些 方法，但是大都很费时，而且精准度欠佳。</p>

<p>和用户一起验证设计方案的方法有很多，较为简单的比如与用户进行非正式的谈话。谈话 中设计人员负责解释产品思路和草图，看看用户是如何想的。复杂一些的比如严格的可用性测 试 （usability test),
    让用户执行一些预先设计好的任务等。每种方法都有各自的优势，方法越 是非正式，进行起来越自然轻松，也越不需要准备。这种方法有些不足之处，因为设计者给用 户做了大量的解释，因此会感觉到有 “ 故意引导证人 ”
    之嫌。一般来说，我们发现这种方法对 于技术型的用户比较适用，他们有能力从几幅草图中想象出产品的大概界面。如果设计团队没 有足够的时间来准备正式的可用性测试，则这是一种非常好的替代方法。</p>

<p>如果时间充足，我们更倾向于正式的可用性测试，它可以用来判断设计能在多大程度上帮 助用户完成具体任务。如果测试的范围足够大，则通过测试你还可以了解一个设计在多大程度 上可以帮助用户实现其最终目标。</p>

<p>更明确点说，可用性测试的本质是评估（ evaluate), 并非创造（ create )。所以他不能代替 交互设计，永远也不可能成为伟大创意的源泉，无法创造吸引人的产品。实际上，它是用来评
    估你既有设计思想的有效性及完整性的一种方法。</p>

<p>可用性测试也不同于用户研究，有些人认为 “ 测试 ” 也是一种研究活动，比如访谈、任务 分析，甚至包括创造型的 “ 参与式设计 ” 活动，这就在一个活动中混淆了不同的需求和设计的 不同阶段。</p>

<p>用户研究肯定是在构思阶段之前进行的，可用性测试一定是在构思阶段之后。实际上，如 果受时间限制，我们不得不在人种学研究和用户测试中做出选择时，就会发现多花费时间进行</p>

<p>114<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 5 章设计产品：框架和提炼</p>

<p>研究更有利于创造出令客户青睐的产品。同样，在时间和投资都有限的情况下，我们发现时间 和金钱花费在产品设计进程中，比花费在测试上更有价值。在坚实的研究基础上，花费时间来
    精心考虑设计决定，比在没有目标用户及其目标和需求、没有完善清晰模型的情况下，对半生 不熟的设计方案进行测试要重要得多。</p>

<p><span id="filepos0000736305"></span></p>

<p>测试 “ 什么 ”</p>

<p>由于可用性测试的发现通常是定量的，因此可用性研究在比较具体设计变量从而选择最有 效的解决方案这一方面尤其有用。当你需要验证或修正某种交互机制、形式或特定设计因素表 达等时，可用性测试中收集的顾客反馈作用最大。</p>

<p>可用性测试在验证内容时尤为有效：</p>

<p>• 命名 —— 部件 / 按钮标签是否合理？某些词语反响是否更好？</p>

<p>• 组织 —— 信息是否进行有意义的分类？用户能否在想找的位置找到特定的部件？</p>

<p>• 初次使用和可发现性 —— 常用项目是否易于新用户的寻找？指令是否清晰、必要？</p>

<p>• 有效性 —— 顾客能否有效完成具体任务？有没有犯错？哪里出错？是否经常发生？</p>

<p>值得注意的是，从属性上讲，可用性测试关注产品初次使用的评估。通常很难测评解决方 案在若干次使用后的有效性，换句话说，很难满足永久的中级用户这一最常见的目标。对中级
    用户或骨灰级用户进行设计优先级排序的确是个难题。不过，也有一个小技巧，那就是使用日 志研究方法，将产品交互细节按照记日记的方法记录下来。在《观察用户体验》认 e — 书中，伊丽莎白 • 古德曼等人对这一技巧进行了详细阐释。</p>

<p>进行可用性测试的时候，要确定测试的内容可被测量，测试能够得到正确管理，测试结果 有助于改正设计问题，并且要确保能到获得解决可用性研究中发现问题所需要的资源。</p>

<p><span id="filepos0000739362"></span></p>

<p>何时测试：最终性评价和形成性评价</p>

<p>在 1993 年出版的《可用性工程》办 — 书中，雅各布•吉尔森对最终 性评价和形成性评价 （formative evaluations) 进行了区分，二者间有一个重要的不同，前者是
    对已完成产品的测试，后者是对设计过程中交互过程的某一部分进行的测试。最终性评价用于 产品的比较，在重新设计开始前找出问题，并对召回产品以及要求培训和支持的产品进行原因
    调查。最终性评价一般由第三方评估机构主导和最终记录。某些情况下，尤其是与对手产品比 较的时候，最终性研究能够发布具有统计意义的定量数据。</p>

<p>遗憾的是，通常只是在产品开发过程接近尾声的时候，最终性评价才会作为质量保证过程</p>

<blockquote>
    115
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>的一部分被使用。而这时，要想做出有意义的设计改变为时已晚。设计应该在编程开始之前进 行评估，或者至少要有足够的时间进行调整。然而，如果要说服涉众或开发人员相信当前产品
    的确存在可用性方面的问题，最好让他们亲眼看看实际用户在操作基本任务时的挣扎。</p>

<p>形成性评价是设计过程中的一些快速且定性的测试，一般来说在提炼阶段进行。精心设计 并运用得当的形成性评价可以开启一扇了解用户思想的窗户，让设计者看到目标用户群对于帮 助他们完成任务的这些工具和信息的反应如何。</p>

<p>不过最终性评价也有其价值。作为产品和应用管理活动，他们能够为产品生命周期的规划 提供信息。他们也是设计开发中有用的 “ 灾难检查员 ” ，排查隐患。但是要在这个阶段进行设计 上的改变，金钱、时间及士气等方面的代价会很大。</p>

<p><span id="filepos0000742543"></span></p>

<p>进行形成性可用性测试</p>

<p>如何解释和进行可用性测试，仁者见仁智者见智。不过遗憾的是，我们发现其中很多方法 不是试图取代正面的设计决定，就是过于量化，产生任务时间之类无法操作的数据。我们发现 , 卡罗琳斯奈德的著作《纸质原型》（ PflperPm 如〇 ^&gt;2g)
    — 书，介绍了可用性测试的多种方法。 这些方法能够很好地配合目标导向交互设计方法。这本书并未讨论所有的测试方法，也没有讨 论关于测试和设计的关系。但是它较好地覆盖了一些基本原则，提供了一些相对容易使用的可 用性测试的技术。</p>

<p>简言之，要确保形成性测试成功进行，需要做到以下几点：</p>

<blockquote>
    • 测试时间不能太早，要在基本的设计成型之后开始，这样才能有实质性的内容可供测 试；也不能太晚，这样一旦发现问题，还能对设计和实现进行调整。
</blockquote>
<blockquote>
    • 要挑选适合现有产品的测试任务和用户体验内容。
</blockquote>
<blockquote>
    • 从目标用户群中招募参与人员，并以人物模型为指导。
</blockquote>
<blockquote>
    • 让参与测试人员清晰地执行规定任务，并采用出声思考的方式。
</blockquote>
<blockquote>
    • 直接让参与测试人员使用技术含量低的原型（也有一些例外，比如专业硬件的测试， 这时候纸质原型无法将具体的交互一一反映出来）。
</blockquote>
<blockquote>
    • 协调各个会议讨论，从而确定问题，找出问题的起因。
</blockquote>
<blockquote>
    • 让之前未参与该项目的人充当协调者，从而尽可能减少偏见。
</blockquote>
<blockquote>
    • 关注实验参与者的行为及其基本原理。
</blockquote>
<blockquote>
    • 测试后和观察者一起听取报告，找出并确定所观察到的问题的原因。
</blockquote>
<blockquote>
    • 在研究过程中要有设计者参与。
</blockquote>
<p><span id="filepos0000746801"></span></p>

<p>设计者参与可用性研究</p>

<p>设计者和用户之间存在相互不理解是导致可用性问题的常见原因。人物模型有助于设计者 了解用户的目标、需要、观点和态度，为有效的沟通奠定了基础。可用性研究，为用户思考问 题打开了一扇窗，让设计者了解到用户与产品互动时的真实想法。</p>

<p>设计者（或者更广泛些，包括哪些设计决策者）是可用性研究结果的主要受益者。尽管在 研究中设计者的参与客观上很难完全保持中立，但是他们在研究计划阶段的参与、研究过程中
    的直接观察，并且参加分析和问题解决讨论等对于研究成败至关重要。我们发现，重要的是要 让设计者采取以下几种参与方式：</p>

<p>• 将重点放在设计过程中的重要问题上。</p>

<p>• 使用任务角色和其特性制定实验参与者的标准。</p>

<p>• 运用场景开发用户任务。</p>

<p>• 观察测试过程。</p>

<p>• 和其他人一道共同分析研究中的发现。</p>

<blockquote>
    117
</blockquote>
<p><font size="7">第6章</font></p>

<p><span id="filepos0000749141"></span></p>

<p align="right" height="1pt" width="0pt"><font size="7">创造型团队合作</font></p>

<blockquote>
    在本书的介绍中，我们曾提到，目标导向方法包含三方面内容，即原则、 类型和过程。然而，还有一点值得提及 —— 实践。本书花费了大幅篇幅讲述上 述三方面内容，我们希望能在本章跟大家分享一些关于目标导向设计的实践，
    以及设计团队如何融入更大的产品团队。
</blockquote>
<blockquote>
    在设计和商业活动中，团队很常见，但鲜有成功或者有成效的团队。团队 合作的奥妙之处不可言传。这些并非团队合作的先天之不足，但假若不仔细揣 摩、细细看护，结果也只能是各方妥协后的折中方案。很多时候，团队成员不
    是过于迁就他人的想法就是太过固执地坚持己见。
</blockquote>
<blockquote>
    如果你有高效率团队合作的经验，就会知道协同工作出成效何其艰难，有 时对单个个体来说简直是天方夜谭。在软件和服务开发的过程中，我们需要团 队合作伙伴帮助我们解决相应的问题、有效地评估创意和解决方案，以及快速
    确定方案是否走入死胡同。运转良好的团队的确能够使产品开发过程更加高效， 结果能够更利于用户。
</blockquote>
<blockquote>
    本章主要讲述三方面内容：一是团队合作的战略；二是产品开发的正确 方法；三是整合不同组织间团队合作的技巧。有些最有趣、最重要的设计问 题太大以致无法单独解决。通常，这些问题牵扯过多，很难拋开其他问题而 单个解决。
</blockquote>
<p>118<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 6 章创造型团队合作</p>

<p><span id="filepos0000752353"></span></p>

<p><font size="6">小而专注的团队</font></p>

<p>以下讨论主要在两个层面对团队的概念进行阐释：</p>

<blockquote>
    • 核心团队小而专注。通常团队成员由各个领域的专业技术人员组成，确保团队能够掌 握工程学技术、创造力、市场调查或商业领导力等领域知识。即便如此，在初始阶段， 依旧可以组建小规模、跨功能的团队或小型产品团队。
</blockquote>
<blockquote>
    • 扩展后的团队规模较大，有时按照地理位置分布，包括涉众在内，他们的工作虽然主 要依赖设计结果却不对设计本身负责。几乎在每个产品的开发过程中，扩展团队都至 少包括若干个核心团队，专注于市场、设计和工程各领域。
</blockquote>
<p>即便在大范围的产品团队中，大多数的实质工作也都在核心团队内完成。因此，本章主要 讲述了能够提高小规模团队合作的若干技巧。不论团队是否是跨功能抑或专注于产品开发的某
    一具体环节，本章的战略都能通过一系列简单的实践加强团队的组织和建设。这些实践有助于 保证创意和工作的高效完成，确保及时做出评论。</p>

<p><span id="filepos0000754143"></span></p>

<p><font size="6">共同思考更好</font></p>

<p>小团队不断地进行优先排序，逐条完成工作任务单上列出的任务。有些不过是细枝末节的 任务，但也要进行优先排序，对其给予适当的考虑。有效的功能性或跨功能性团队在碰到此类
    无止境的任务排序时，他们不仅会对任务分而治之，还会利用团队成员的思想火花甚至有时混 乱的思绪，我们把这叫作 “ 思想伙伴”。</p>

<p>你可以把思想伙伴想象成思想的补充，当做一位合作者，与你有共同的目标但掌握不同的 技术，能从不同的角度考虑问题。在《思考，快与慢》 am/ 观 w) — 书中，作者 丹尼尔 • 卡尼曼 （Daniel Kahneman)
    描述了自己同阿莫斯 • 特维斯基 （Amos Tversky )在学术 领域的合作，在我们看来，这一种合作模式就是很好的思想伙伴关系。</p>

<p>“我们在一起工作中发现的乐趣让我们格外耐心；当你不感到枯燥乏味的时候才更容易追求 完美；阿莫斯和我两个人都很挑剔，也爱争论 …… 但在多年的合作中，我们从未拒绝过另一个 人的想法。”①</p>

<p>① ICahneman, 2011，p 5</p>

<blockquote>
    119
</blockquote>
<p>About Face 4 :交互设计精糖</p>

<p>思想伙伴如何演变而来？在库伯早期的咨询实践中，其中有一个会议室逐渐被人们称作 “ 吼叫室 ” 。（这个名字就证明了简单的雇用想法类似的人并不能保证设计过程的永久和谐。）如
    今，设计者们参加竞选，大声说出自己的设计创意是一件很普通的事情。团队合作的精神实质 是协作和思维的活跃性，但结果通常并不明朗。 “ 我们又做了什么决定来着？ ”“谁的创意更胜 一筹？ ”“ 我们现在需要解决什么问题 ？”</p>

<p>随着时间的过去，一种新的合作战术出现了。两个设计师中，一个负责整理访谈内容，另 一个则集中精力启发探索访谈对象。在我们今天的实践中，我们对以下两种方法进行了更深层 次的定义和区分。</p>

<blockquote>
    • 创意创造 —— 在以创造为基础的方法中，可以进行无边无际的创意构想，当人们能够 自由地创造、思考和探索，结果才是最成功的。
</blockquote>
<blockquote>
    • 创意综合 —— 在以综合为基础的方法中，需要对创造进行指导和聚焦，这样的创造才 最能结出硕果。只有用户需求得到满足，设计结果才能得到保证。
</blockquote>
<p>解决复杂问题时，团队如能灵活使用上述两种方法，就能快速取得进展。无论你在产品开 发过程中扮演何种角色，都可以使用以下措施来寻找团队伙伴帮助你做出最好的构思和创意。</p>

<p><span id="filepos0000759417"></span></p>

<p>创造者和综合者</p>

<p>在 Cooper 的招聘过程中，我们试图寻找强大的思想伙伴，尤其是掌握创造者不同技术或心 理的人才。我们称这类人为创造者和综合者。我们发现，在处理相对复杂的设计难题时，这两
    种不同风格的创新能够达到强有力的平衡。创造者和综合者肩负不同责任，而须用简单的方法 取悦用户。最好的情况是，他们允许团队伙伴全身心地投入各种创造性的角色中，完全自如地</p>

<p>表演。</p>

<p>如图 6-1 所示，创造和综合处于相同的创新光谱内。大多数设计者喜欢非此即彼地在二者 中进行选择。厉害的创造者通常需要与同样优秀的团队伙伴合作，从而达到一种健康的平衡。
    当孤身奋战时，强大的创造者可能会不假思索地投入到一个不完整的设计方案中或者过分沉湎 于头脑风暴。他们需要一个综合者来帮忙在合适的时间合适的阶段做出决定，从而保证设计过 程顺利进行。</p>

<p height="0pt" width="0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>

<p align="center" height="0pt" width="0pt"><img class="responsive-img" align="baseline" alt=""  src="../Images/Image00166.jpg"/></p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 图 <font size="2">6-1</font> 创新光谱中的创造和综合</p>

<p><br/>
    <br/>
    <br/>
    <br/></p>

<p>&nbsp;</p>

<p>第 6 章创造型团队合作</p>

<p>综合者开始会在团队内部开始对话。他们会针对已提出的创意提问一些意图和价值方面的 问题，而非直接提出新创意和解决方案。随着谈话的进行，综合者会明晰思路，找出差距并建
    立联系。独自工作时，强大的综合者能够努力超越列表和场景进行思考。</p>

<p>创造与综合之间求得平衡时的对话会对评估和合理性探寻的设想有所启发，它为复杂交互 问题的解决奠定了强大的团队伙伴基础。创造者的想法开始时可能比较模糊，或者激励人心，
    而能干的综合者能够快速发现其中内含的价值或者直接终结，而伙伴们会很快认识到这点，迅 速了结。</p>

<p>下面一小节内容主要描述了不同角色的品质、特征和相互作用，将比较作为一种手段来寻 找自己的创新战略，并描述能够将你最好一面展现出来的那类人。</p>

<p>如图 6-2 所示，在典型的设计讨论会上，不同角色的差别通常会在第一时间就显现出来。 当遇到设计问题时，谁会立即拿起笔走向白板？</p>

<p><font size="2">创造者</font></p>

<p><font size="2">综合者</font></p>

<p><font size="2">最经常看到的是</font> …• <font size="2">解决设计问题时</font> …• <font size="2">考虑设计方案时</font> …•</p>

<p><font size="2"><font color="#FFFFFF">白板前，_笔在手</font></font></p>

<p><font size="2"><font color="#FFFFFF">构思问题，摩挲下巴</font></font></p>

<p>设想新的设计方向</p>

<p>询间親麵</p>

<p><font size="2">图</font> 6-2 <font size="2">创造者和综合者相互补充</font></p>

<p>在设计会议进行期间，每个角色都倾向于停留在一定的物理和心理距离内。成功的创造者 趋向于拿起笔将想法画出来，如图 6-3 所示。综合者则倾向于列出好的方案的优点或者重新了 解问题、用户目标和使用情境。</p>

<table align="center" valign="top">
    <tr valign="top">
        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p>&nbsp;&nbsp;</p>
        </td>

        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p align="center" height="0pt" width="0pt"><font size="2">&nbsp;</font> <font size="2">创造者</font></p>
        </td>

        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p align="center" height="0pt" width="0pt"><font size="2">&nbsp;</font> <font size="2">综合者</font></p>
        </td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p>&nbsp;&nbsp;</p>
        </td>

        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p height="0pt" width="0pt"><font size="5">T&nbsp;</font></p>
        </td>

        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p height="0pt" width="0pt">T&nbsp;</p>
        </td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <blockquote>
                <font size="2">&nbsp;</font> <font size="2">淸晰地将体验描述成</font>
            </blockquote>
        </td>

        <td bgcolor="#000" valign="top">
            <span bgcolor="#000000">&nbsp;</span>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">&nbsp;</font></font> <font
                    size="2"><font color="#FFFFFF">绀具体的创怠</font></font></p>
        </td>

        <td bgcolor="#000" valign="top">
            <span bgcolor="#000000">&nbsp;</span>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">&nbsp;</font></font> <font
                    size="2"><font color="#FFFFFF">具有具体情节点的故事</font></font></p>
        </td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <blockquote>
                <font size="2">&nbsp;</font> <font size="2">以……的形式输入</font>
            </blockquote>
        </td>

        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p align="center" height="0pt" width="0pt"><font size="2">&nbsp;</font> <font size="2">创造</font></p>
        </td>

        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span>

            <p align="center" height="0pt" width="0pt"><font size="2">&nbsp;</font> <font size="2">说明</font></p>
        </td>
    </tr>
</table>

<p><font size="2">图</font> 6-3 <font size="2">创造者和综合者从不同的角度思考设计问题</font></p>

<p><br/>
    <br/></p>

<p>创造者是构思具体化的不懈思想者，而最棒的综合者则倾向于讲故事和提示。 下面是想象性项目的示范讨论：</p>

<p>121</p>

<p><br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/>
    <br/></p>

<p>About Face 4 :交互设计精髓</p>

<p>创造者：我有个想法可以添加到列表上去。（开始在白板的屏幕上写画。）这是一种姿态。 当你在主列表上下拉列表时，你会看见一个控件，可以添加新内容。它就是一个空白域。</p>

<p>综合者：太棒了！不过这可能有点隐藏的感觉。在杰夫的情境中，他只是隔几周才添加一 些新东西，对吗？</p>

<p>创造者：对，倒没错。他可能忘了这个东西。</p>

<p>综合者：不过我喜欢这个想法，它一直关注信息而不是用户界面的插件。</p>

<p>创造者：嗯。当主界面加载时，我们在显示这个空白域的同时加一个帮助文本“添加新内 容 ” ，随后界面会跳出来覆盖掉这一内容，这样如何？既能看到内容，又能继续关注列表。</p>

<p>综合者：我觉得不错。如果会议当中，它跳出好几次，我可能会觉得很烦，但是我想我们 可以给它制定点规则。</p>

<p>随着设计会议的进行，创造者和综合者一道探索解决方案，思考各个创意。综合者能够帮 忙组织整个讨论，轻微地控制域的深度。谈话通常以广泛讨论问题开始，接着会逐步加深讨论 解决方案的细节问题。</p>

<p>正如图 64 所示，不同创造性思维方式之间通常存在矛盾，尤其是从不同角度思考问题时。 创新性伙伴关系确立的早期，要建立相互间的信任。创造者必须主导概念性方向，这意味着综
    合者必须有文字和象征意义上的主导权。同时，创造者必须相信综合者能够主导整个讨论，避 免陷入细节泥淖，并且在必要的时候要对问题进行重新构思。这意味着，创造者必须习惯于介
    绍新想法，不惧怕合作伙伴对这些想法的评价和挑剔。毕竟，大多数想法不是什么好主意。思 想伙伴的主要目标就是确定创意、想法的品质或者早点判定想法该继续还是摒弃。</p>

<p><br/>
    <br/>
    <br/>
    <br/></p>

<table align="center" valign="top">
    <tr valign="top">
        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span> &nbsp;<br/>
            <br/>

            <p align="center" height="0pt" width="0pt"><font size="2">创造者</font></p>

            <p align="center" height="0pt" width="0pt"><font size="5">丄</font></p>

            <p align="center" height="0pt" width="0pt"><font size="2">综合者</font></p>

            <p height="0pt" width="0pt"><font size="5">T</font></p>

            <blockquote>
                <font size="2">承担的责任</font>
            </blockquote>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">主导概念方向</font></font></p>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">保概念连贯性和致性</font></font></p>

            <blockquote>
                <font size="2">能够轻松地进入</font>
            </blockquote>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">过于细致的细节</font></font></p>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">先入为主的分析</font></font></p>

            <blockquote>
                <font size="2">当创造性的平衡被打破</font>
            </blockquote>

            <p align="center" height="0pt" width="0pt"><font size="2">沉溜于某一方案不可自拔</font></p><br/>
            <br/>

            <blockquote>
                <font size="2">当创造性平衡实现时</font>
            </blockquote>

            <p align="center" height="0pt" width="0pt"><font size="2">自由实践想法并且探索 不同的解决方案</font></p><br/>
            <br/>
            <br/>
            <br/>
        </td>

        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>
    </tr>
</table>

<p><br/>
    <br/></p>

<p><font size="2">图</font> 64 <font size="2">创造者和综合者有不同的责任和优缺点</font></p>

<p align="right" height="0pt" width="0pt">第 6 章创造型团队合作</p>

<p>如图 6-5 所示，在细节设计 （detailed design) 阶段，设计团队通常早上一起工作，然后各 自处理自己负责的细节设计。创造者通常会取出画笔，开始用写画的形式捕捉设计决定。综合
    者对设计决定的捕捉则是通过图表方式帮助解释设计流程或者以文章的形式解释基本理论。设 计团队记录的各个细节可以根据团队的规模大小和需求，通过多种方式进行交流。根据我们的
    经验，我们更喜欢急促的、轻便的、非正式的笔记而不是正式的文件记录方式。</p>

<p><br/>
    <br/>
    <br/>
    <br/></p>

<table align="center" valign="top">
    <tr valign="top">
        <td bgcolor="#FFF" valign="top">
            <span bgcolor="#FFFFFF">&nbsp;</span> &nbsp;<br/>
            <br/>

            <p align="center" height="0pt" width="0pt"><font size="2">创造者</font></p>

            <p height="0pt" width="0pt"><font size="5">T</font></p>

            <p align="center" height="0pt" width="0pt"><font size="2">综合者</font></p>

            <p align="center" height="0pt" width="0pt"><font size="6">y</font></p>

            <blockquote>
                <font size="2">会议结束后</font> ……
            </blockquote>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">画出交互结构和流程</font></font></p>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">用大致的阁文捕捉设计
                决定的雎本原理</font></font></p>

            <blockquote>
                <font size="2">关注于理解</font> ……
            </blockquote>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">设计决定的流程和暗示</font></font></p>

            <p align="center" height="0pt" width="0pt"><font size="2"><font color="#FFFFFF">某模式语言的开发</font></font></p>

            <p align="right" height="0pt" width="0pt">图6-5创造者和综合者在白板前操作各自不同的任务</p><br/>
            <br/>
        </td>

        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>
    </tr>

    <tr valign="top">
        <td bgcolor="#FFF" valign="top"><span bgcolor="#FFFFFF">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>

        <td bgcolor="#000" valign="top"><span bgcolor="#000000">&nbsp;&nbsp;</span></td>
    </tr>
</table>

<p><br/>
    <br/>
    <span id="filepos0000779602"></span></p>

<p><font size="5">与思想伙伴的起始合作</font></p>

<p>当你在实践中想要建立思想伙伴关系的时候，你可以先开始创建创造者或综合者角色，然 后寻找合适的人选。更简便一点，你可以先寻找一些小的方法，采用适合你的工作的一些实践
    方法。这种方式对于确定你所需要的伙伴来说花费时间较长，但优点是可以从简单处着手。</p>

<blockquote>
    思想伙伴要满足以下几点：
</blockquote>
<blockquote>
    • 开始工作前能够明晰你要解决的问题。
</blockquote>
<blockquote>
    • 向具有创造能力的同事或者朋友求助： “ 我需要一个伙伴帮我启动一些想法 。”
</blockquote>
<blockquote>
    • 如果事情在会议开始时行不通，直接走到白板前，写出一个烂主意。如果你的伙伴是 位优秀的创造者，他/她会跳出来继续按照你的思路进行设计或者干脆给你提供一个相 反的建议。
</blockquote>
<blockquote>
    思想伙伴要会综合
</blockquote>
<p>在此之前，要确保 “ 故事 ” 或情境场景具有较高的水平。这有助于你的伙伴在会议过程中 能够明了工作从何干起。鼓励伙伴发挥其评估能力： “ 帮我看一下这个想法怎么样 ？”</p>

<p>如果事情没有立即解决，那就先关注整个故事，确保清晰地了解用户的行为及原因。</p>

<p>动态角色转换</p>

<p>在伙伴关系确立初期就要制定一些基本原则。综合者应该探查并引导；创造者应该探索和</p>

<p align="right" height="2em" width="0pt">123</p>

<p>About Face 4 :交互设计精髓</p>

<p>设想。进行会议过程中，二者可以互换角色，但是最好要简单明确地实现这一转换。当综合者 有了一个好主意时，他必须抑制住冲动，停止创造者的角色演绎。相反，他可以简单地要求转 换角色： “ 能不能让我创造一下 ？”</p>

<p>脱离困境 （15 分钟规则）</p>

<p>富有创造力的小团队有时会遇到诸如想法不连贯、谈话停滞或者纠缠于细节问题之类的挫 折。根据我们的经验，如果讨论停滞超过 15 分钟，我们建议引入另外一位设计者参与讨论。核
    心团队应该简要地向新成员介绍情境设计的细节，如用户、场景、考虑的创意等。反过来，新 成员也要探寻设计者的设计理论和依据，比如这一点好在哪里？有什么用？几乎无一例外，这 种 简单对话能够帮助设计者们从细节和困境中迅速 抽离。</p>

<p><span id="filepos0000784505"></span></p>

<p><font size="5">核心团队规模适度</font></p>

<p>两个成员基本合理，三个更好，四个就会令人惊叹，而十个估计可以扭曲时空了。对不对？ 构建团队的时候，团队无论大小都成为附加物的牺牲品。根据我们的经验，团队成员定位清晰、 规模小而紧凑的团队效率最高。这也是我们使用 “ 核心团队 ”
    这一称呼的原因，它们负责完成 产品的设计工作。</p>

<p><i>i</i> <i>阜趨升级</i> <i>} (Scaling Up Excellence)</i> 一书中，作者斯坦福商业学教授罗伯特•萨顿（Robert
    Sutton)和哈吉•拉奥（HuggyRao)多次举例说明大规模的团队设计结果并不如意，他们把这 一现象叫作 “ 过犹不及”：</p>

<p>“ 规模较大的团队当中，团队成员给予其他人的支持和帮助更少，因为要维持如此众多的社 会关系或同更多人进行协调难度更大 …… 最重要的挑战是如何引入规则、工具和不具创造力的 成员（膨胀 )。” ®</p>

<p>从我们在Cooper公司的实践来看，避免膨胀需要坚持四个原则：团队规模小、角色清晰、 决策紧凑、与工作相关的最少工作量。最后一条原则指的是与产品开发核心目标没有直接促进
    关系的任何活动。诸如邮箱状态和快速、非应急登录之类的小任务都需要巨大努力和协调才能 实现和结束。如果你正在某个不重要的会议上浏览本书内容，你就陷入了 “ 与工作相关的工作 ” 这一流沙中。</p>

<p>通过将决策本地化、规划重要活动和登记信息，我们可以为小型团队发挥创意天分提供空 间。从具体数量上讲，单个问题的解决需要核心团队保持 2 〜 4 个成员的规模。至少两人才能保</p>

<p>① Sutton and Rao, 2014</p>

<p>124<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 6 章创造型团队合作</p>

<p>证快速评估和迭代。超过四个成员就会有过多的间接成本，太多要迎合的人，以及失去设计动 力的更大风险。</p>

<p>最后，要记住只有团队成员角色清晰、权责明确、能力互补，小规模团队才能发挥战斗力。 下面小节主要讨论大、小团队当中形色各异的参与者，以及发挥其最大作用的小技巧。</p>

<p><span id="filepos0000788534"></span></p>

<p><font size="6">跨设计领域工作</font></p>

<p>在创意讨论过程中，任何专业人员都可以使用综合 - 创造模式。根据我们的实践，视觉设计 者和交互设计者、两个交互设计者、设计者和开发人员或交互设计者与创意指导等任何两个设
    计者协作时，这一模式都能为其提供框架结构。当用户体验设计逐渐确定之后，工作人员通常 会发现他们又步入一种新的阶段，即同拥有众多背景的创意专业人员进行协作。综合-创造模式 能够有效运用于不同领域专业人员组成的各种核心团队。</p>

<p>产品的生命周期当中，不光需要跨领域设计者们的交流。交互设计者必须同视觉和行业设 计者进行合作，对决策进行筹划，这样才能确保每个领域都配备了各自所需要的材料，从而实 现最高效率的工作 。以下
    小节为了解每一领域明确的责任提供了整体框架，同时还简要概述了 如何确保各个领域有效的协作。</p>

<p><span id="filepos0000789925"></span></p>

<p align="right" height="1em" width="0pt">交互设计</p>

<p>交互设计者负责了解及明确产品的行为方式。这一工作同视觉和工业设计师在很多重要方 式上有重叠之处。设计物理产品时，交互设计者必须尽早同工业设计师一起明确实物投入的需
    求，了解其背后机制的行为影响。在设计项目过程中，交互设计者同视觉设计者总会不期而 遇。在实践中，他们的协作早在视觉设计者同用户和扩展团队间讨论品牌和体验的易感性时就 开始了。</p>

<p><span id="filepos0000790610"></span></p>

<p align="right" height="1em" width="0pt">视觉界面设计</p>

<p>在实践中，我们逐渐意识到视觉界面设计 （Visual Interface Design )是一个重要而不同的领 域，必须同交互设计，或者合适的话，同工业设计保持一致。它能在很大程度上影响产品的有
    效性和吸引力。但是，要确保这一点，设计者就不能在事后才考虑视觉设计的事情，它并非设 计结束后的锦上添花，而应该被看作满足用户和商业需求必不可少的一个工具。</p>

<p>视觉设计者的工作主要强调设计的组织方面以及视觉暗示和启示同用户行为的交流方式。</p>

<p align="right" height="9pt" width="0pt">125</p>

<p>视觉设计者必须同交互设计者们密切协作，了解信息重点、流程和界面的功能并确定产品正确 的情感基调。</p>

<p>视觉界面设计者关注如何将用户心理模型和应用模型的界面视觉结构同逻辑结构相匹配。 他们还关心用户交流应用的状态，如只读和可编辑，以及围绕用户功能概念方面的认知问题， 譬如布局、视觉层次、图形 - 背景问题等。</p>

<p>视觉界面设计者们必须掌握基本的视觉特性，如颜色、排印、形式和组成等，并且必须知 晓这些元素如何有效地传递启示、信息层次和情绪。视觉界面设计者们应该了解品牌心理学、
    平面设计的历史，熟悉当前的流行趋势，必须掌握可用性原则和人类感知的科学。视觉界面设 计者们同样需要对界面规则、标准和惯例有初步的了解。（关于目标导向视觉界面设计的更多内 容参见第 17 章。）</p>

<p><span id="filepos0000792978"></span></p>

<p>平面设计</p>

<p>直到大约 20 年前，平面设计领域一直被普通的油墨所控制，它被用于包装、广告、环境视 觉设计和文档设计。这些传统实践无法满足以像素为基础的产品的需求。然而，在过去 20 年间，
    这一领域取得了相当大的进展，平面设计日益活跃、强大于数字和屏幕媒介的产品设计中。</p>

<p>既能够熟练运用数字技术又有才华的平面设计师精于创造丰富、符合审美需求并且激动人 心的各种界面。他们能够设计出漂亮、恰当的界面，传递某种情绪或者同某一公司品牌建立联
    系。对于他们来说，设计首先是同品牌体验相关的一种基调、风格和框架，其次是易读性和信 息的可读性，最后是通过视觉启示实现的交际行为（参见第 13 章）。</p>

<p><span id="filepos0000794256"></span></p>

<p>视觉信息设计</p>

<p>视觉信息设计关注的是数据、内容和导航的视觉化，而不是交互功能。不同于信息设计， 它很少关注内容的可编辑性和信息的结构性问题，而是关注平面设计的展现。这一点在设计数 据密集型应用时尤其重要，用户大部分时间用在复杂的内容上面。</p>

<p>视觉信息设计的主要目标是以一种易于理解的方式展现数据。通过使用排印、颜色、形状、 位置和比例等视觉特性以及变幻方式可以控制信息层次，从而实现上述目标。视觉信息设计还
    包括显示信息的微观交互，它展现了一些细节或与其他信息之间的联系。视觉信息设计的应用 通常包括表格、图形、迷你图和其他形式的定量信息的显示。爱德华 • 塔夫特（ EdwardTufte) 在包括《定量信息的视觉显不》阶 wfl/Z)
    却/吵等多本研讨性著 作中曾详细讨论了这一问题。</p>

<p><span id="filepos0000795685"></span></p>

<p>工业设计</p>

<p>在趋同性产品的设计中，工业设计师必须定义物理产品的外形，利用形状和材质来展现品 牌。为了实现交互设计的目的，他们还制定了实物投入机制。交互设计者能够从将用户整体需
    求和设备目标作为一个整体进行研究。工业设计师利用具有竞争力的分析和材料研究为其设计 理念奠定坚实基础。投入机制的确定要晚于希冀的交互模式的确定。软件主要元素的交互迭代
    应该同工业设计理念一起执行，这样每一次输出都能预示相应的阶段。自始至终，交互设计者 都受益于工业设计师在材料和人体工程学领域的专业知识，而工业设计师也受惠于交互设计者 创造的整体设计体验理念。</p>

<p>同平面设计者和视觉界面与信息设计者技术上的区别类似，不同等级的工业设计师之间也 有相似的差别。有些设计师擅长创造具有吸引力的、恰当的产品外观，而有些设计师则注重以
    用户目标和设备交际行为相匹配的方式实现产品逻辑性和人体工程学映射的物理控制。使用丰 富视觉显示的软件设备的增加，需要交互设计者、视觉界面设计者以及工业设计师一道努力创 造完整而有效的设计方案。</p>

<p>许多优秀的著作都对这些角色之间细微的相互作用有所涉猎。金古德温在《数字年代的设 计》 (Wiley ， 2011) — 书中，为角色定义和项目情境下思想伙伴的 创建提供了实际操作的技巧和提示。</p>

<p><span id="filepos0000797702"></span></p>

<p><font size="6">扩展团队</font></p>

<p>我们在前面章节对小型核心团队如何进行伟大的设计进行了讨论。但是要将设计转换为实 实在在的产品，设计师们需要了解更多人的想法和心思。扩展团队的其他成员是否理解设计的
    价值？他们是否会仔细研究这一方案并对其进行评价以使其更加完善？即使能够通过早期的白 板会议讨论环节，设计方案能否在展示阶段获得客户的赞同？假设客户赞同，这一方案又能否 被产品工程师们理解、执行并有效地延展？</p>

<p>下面我们试图描述将设计融入大部分产品设计团队的一些简单战略。我们不打算对产品或 服务设计和开发的最佳实践进行整体概述。真正伟大的创意很少。这也是为什么无论核心团队
    还是扩展团队，都需要有能力的协作者给予及时、真诚反馈的原因。本节内容主要对产品团队 中通常最重要的参与者进行讨论，重点讨论如何以及何时与其合作，从而确保在恰当的时间获 得他们对产品设计的中肯评价。</p>

<p align="right" height="3em" width="0pt">127</p>

<p><span id="filepos0000799181"></span></p>

<p>责任和权威</p>

<p>创造伟大的交互体验不能光靠设计者一己之力。在数字产品组织中，工程师的专业经验、 市场人员和商业涉众必须加入产品创造和开发的设计过程中。以下内容描述了不同领域设计人 员的不同责任和相同的权威。</p>

<blockquote>
    • 设计要对目前产品用户目标负责。当前，很多产品组织并未明确将用户目标列为某个 个人或团队的责任范畴。要履行这一责任，设计师必须有权决定产品的外观、感觉和 行为。他们还应该有权获得信息。设计师需要观察并同潜在用户进行访谈，了解其需
    求，向工程师了解技术机遇和限制条件，向市场人员了解市场机遇和需求，向管理人 员了解组织期望的产品设计模式和结果。
</blockquote>
<blockquote>
    • 可用性要对验证用户对设计预期的反应负责，并对验证整体体验和细节交互是否具有 预期效果，即是否有用、可用和令人期待等负责。为确保设计的有效性，需要保持可 用性的独立，但也要同设计团队进行协作。另外，可用性和设计都应该向决策者报告，
    决策者能够在正式、客观的角度上衡量各项结果，并有权对设计或者执行进行必要的 修改。可用性的优势在于它能够确定问题所在，而设计的强项在于制定解决方案。只 有合理分配人力，才能保证协作达到最佳效果。
</blockquote>
<blockquote>
    • 工程师负责设计的建造。这意味着他们必须有权决定原材料的选择和建造过程，譬如 开发平台和库，以及产品待办列表中相对困难的估价和物品的成本。当对这些物品进 行了优先级排序，工程和设计团队应该相互告知。设计师必须对产品形式和行为的执
    行进行回顾并做出反应。工程和设计两个团队必须评价产品开发和测试过程中整体体 验的成与败。设计者们应该依赖工程师提供技术限制条件和机遇，以及所提供的设计 方案的可行性方面的指导。
</blockquote>
<blockquote>
    • 市场营销负责定义市场机遇，了解客户需求、喜好和动机。市场团队最终必须说服客 户购买产品。要实现这一目的，市场团队必须有权在顾客环节提倡最赚钱、最实惠的 设计方式。团队成员必须为恰当的用户目标设计研究提供指导，并且有权获得设计研
    究相关的结果。（值得一提的是，正如我们在第 3 章所讨论的，顾客和用户通常是不同 的群体，有着不同的需求。）
</blockquote>
<blockquote>
    • 商业领导通常负责定义商业机遇，因为他们也负责保证产品的赢利。这个群体必须决 定何处为产品差异化的机遇所在，以及扩展性团队中重要的特性和功能是什么。要做 出这些决定，商业领导们需要从其他团队中获得清晰的信息，比如设计研究和产品定
    义、市场研究和销售规划、工程师关于创造产品的时间和成本等。
</blockquote>
<p>有两个地方需要不同团队之间的协作：一是意识到经常性的、非正式的工作会议是新想法 探索、评价和阐述的地方；二是已建立设计过程中对应每个阶段结束的检查点 <font size="2">。一</font> 旦设计确定，</p>

<p align="right" height="0pt" width="0pt">第 6 章创造型团队合作</p>

<p align="right" height="2em" width="0pt">工作会议对工程师来说尤为重要。同样，在设计项目开始和后期阶段中，会议对于市场团队来</p>

<p>说也至关重要。</p>

<p>随着产品设计理念的进化，每个团队都要不断寻求解决核心关注的方式：</p>

<p>• 设计者：打造用户体验的最简单、最连贯以及最能激发快乐的机制是什么？</p>

<p>• 可用性专业人员：设计能否传递有用性、可用性和可期待性的承诺？实际情况中，用 户是否按照设计预定的方式使用产品？</p>

<p>• 工程师：如何以快速、有活力、可升级并可延展性的方式传递体验？</p>

<p>• 市场人员：如何激发可采纳性？</p>

<p>• 商业领导：产品功能和市场需求最明显的重合点是什么？</p>

<p>当团队成员关注以上问题并保证其恰当的重要性后，扩展团队的交互就变得清楚、直截了</p>

<p>当。</p>

<p><span id="filepos0000805801"></span></p>

<p>同敏捷开发人员协作</p>

<p>设计师设想并确定正确的体验：能够取悦用户的外观、感觉正确的体验、适合使用的行为。 开发人员提供必要的结果：正确的体验应该以正确的方式进行构建。我们一度认为所有的设计
    工作应该早于编程完成，但我们逐渐认识到这既不合情理也不实际。有条不紊的测试及对设计 假说的可行性证明能够带来实实在在的好处。</p>

<p>敏捷开发方法起源于 “ 瀑布 ” 方法缺点的回应，这一方法经过了数年的开发实践、拥有数 百页的需求文档、经过了多种检验以确保其质量，也有几十位人员参与。敏捷方法试图优化时
    间和能量，减少浪费，保证这些概念能够确切向用户传达设计理念。它同本章开始时讨论的许 多设计原则一样，鼓励建立规模较小的设计团队、专注工作、经常讨论。然而尽管软件开发实
    践不断进化发展，敏捷方法还是属于复杂的设计工作，并且在某些情况下，会发生短路。</p>

<p>本小节主要讨论使用敏捷方法保证设计师工作能够预示并塑造产品开发的方式。我们首先 来了解一下敏捷设计方法的一些基本观点。</p>

<p>商业利益相关者倾向于敏捷开发的创意，因为听起来这种创意比较经济高效。然而商业利 益相关者们通常不会意识到构建速度意味着思考的速度，而快速的思考需要坚实的认识基础和
    期望的结果。如果对于要构造和测试什么内容尚未形成认知基础或还未达成一致意见，那么敏 捷设计也就失去方向，只会是无法兑现承诺，徒劳一场。</p>

<p align="right" height="6pt" width="0pt">开发人员倾向于敏捷设计方法，因为这种方法支持他们的所爱（编程 ) ，反对他们的所恶（坐
    在会议室里开会、反复讨论需求相关文件）。然而，如果滥用这一方法，会出现看不清方向低头</p>

<blockquote>
    129<br/>
    <br/>
</blockquote>
<p>About Face 4 :交互设</p>

<p>拉车的情况，使得设计进入如同瀑布式方法一样令人抓狂的死胡同。</p>

<p>在实践中，当核心产品元素阐释清晰、获得广泛理解并得到执行时，这些元素才能很好地 被测试，敏捷开发也才能获得更大程度的成功。因此，我们发现应该在构建之前，就对产品体
    验的主要元素进行规划、视觉化处理和讨论。即便在高度迭代的过程中，也应该在构建前进行 规划，三思而后行。比起对设计和构建的整齐而有序划分，这事实上更难处理，但是它可以在 设计者、开发者和商业决策者之间启动有成效的对话。</p>

<p>本小节的剩余部分在较高的层次上提出了一些简单问题：</p>

<p>• 在敏捷情境中，设计意味着什么？</p>

<p>• 设计者们应该如何以快节奏、敏捷的方式进行设计实践？</p>

<p>设计者在敏捷团队中的工作</p>

<p>交互设计者追求简单、一致，理解连贯的设计方案不会一蹴而就。这种方案需要经过时间 磨砺才能出现，遵循着安东尼 • 德 • 圣 - 埃克苏佩里 （Antoine de Saint-Exup6ry )经常引用的一 段设计格言： “……
    完美的来临并非意味着无可附加，而是不可删减。”瀑布方法更喜欢这种工 作方式，因为这使得他们有时间开发创意、展现并修改缺陷。敏捷方法珍视速度、关注小的迭 代，但他们为设计者赢取了了解用户对进程中设计解读方式的一个机会。</p>

<p>在敏捷设计中，设计师必须分清重点、形成思维图像；他们可以让期待结果变得清晰具体 , 还可以围绕必须对何种元素进行开发从而实现期待结果这一话题进行对话。这听起来与许多其 他方法的实际工作大同小异，但有一重点是不同的：</p>

<p>敏捷设计允许产品体验定义方面存在矛盾和完全不同的意见。设计者必须有能力对用户体 验的重要因素进行定义，并能够同为其定义制造困难和限制条件的开发人员一道工作。</p>

<p>设计者必须对投入和产出进行不同的思考。敏捷开发允许用户在早期并且经常给予反馈。 这是一种机会，设计人员应该庆幸。</p>

<p>设计人员很少有机会在敏捷设计中对用户体验设想进行完全的视觉化构思和完善工作。但 是他们必须在产品定义和开发事项的优先级排序中提倡目标导向性。</p>

<p>定义敏捷团队中的用户体验</p>

<p>在同敏捷开发人员进行合作的早期，设计者会希望早点评估有多少体验已经被定义、明确 或得到暗示。这种定义可以是由首席建筑师或者商业利益相关者创建的线框图形式一样的清楚
    定义，或者是对如何工作、实现技术使用等一致设想的暗示性定义。设计者应该期望塑造用户 体验的主要元素，比如布局和导航隐喻、信息建筑、建立抛光感的转换和模仿等。因此，重要</p>

<p>130<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 6 章创造型团队合作</p>

<p>的是要应付这些预定的含义和限制。</p>

<p>在最佳的敏捷团队中，设计者确定体验基本的同时开发人员加入非用户面对的技术性基本， 次佳的情况是，设计者需要快速面对假定的规范，尤其这些早早决定的重要的体验内容。这些
    对话可能很难，但是用户体验设计的整体是为了通过用户界面表现产品设想。</p>

<p>从我们的实践经验看，在这个阶段，敏捷开发人员可以作为能干的思想伙伴。有天分的开 发人员对基础设施和交互产品的连接问题思考较深，他们以一种健康的观点看待真正复杂的工
    程问题。最好的情形是，开发人员能为设计应用指出正确的方向并确保设计工作能有效地被执 行。最糟糕的状况是，开发人员或设计人员都无法理解团队其他成员专长的价值所在。</p>

<p>敏捷团队做的有价值的工作同其他团队大体相似。一直都要清晰地表述用户目标、场景和 流程；对期待的产品体验进行视觉化构思和迭代；驱使、收集并解析频繁使用产品或服务的用
    户所做出的反馈。在敏捷团队中，设计人员必须能够快速决定用户的最大体验挑战是什么，并 确保能在产品开发前定义相关的元素流。</p>

<p>想要了解用户体验设计师和敏捷开发人员合作的案例研究，可以参考知名网站 Smashing Magazine 中杰夫 • 戈塞尔夫 （Jeff Gothelf) 与乔西 • 赛登 （Josh Seiden) 合著的《精益设计：
    摆脱交付业务》一文 ® 。这是用户体验设计应用于具体敏捷开发的首秀。</p>

<p>融合用户反馈</p>

<p>对于设计者来说，敏捷设计最具价值的副产品就是用户对体验的反馈。只要恰当的刺激、 收集并给予解读，这种反馈会极为有用。如果你是设计者，重要的是在新特性或者功能发布时 要确定希望从用户反馈中学到什么。</p>

<p>敏捷设计的反馈节奏虽快却不陌生。早期阶段，驱使用户做出反馈时要了解基本的用户假 设是否正确。期待的用户能否得到期望的价值？主要因素为用户提供的服务如何？除了你希望
    的工作外，确定哪些功能正在工作也同样重要。人们使用什么产品？为什么？</p>

<p>随着开发的继续，用户反馈更加聚焦：主要元素进展是否顺利？如何使用？是用什么？哪 些地方用户会出错？哪些功能或设计令用户称奇？</p>

<p>® <a href="http://www.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/">http://www.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/</a>
</p>

<blockquote>
    131
</blockquote>
<p>About Face 4 :交互设计精應</p>

<p><span id="filepos0000818294"></span></p>

<p><font size="6">创建创造性的文化</font></p>

<p>建立设计团队固然重要，但能干的人组成的团队不一定能产生好的设计结果。伟大的团队 之所以出现并成功，是因为他们置身的现实和虚拟环境能够滋养他们。在实践中，设计团队的
    文化和社会活力与清晰的角色同样重要。团队成员是否愿意一起工作？工作中能否获得乐趣？ 他们的工作安排是否和谐？兴趣如何？工作方式如何？有没有幽默感？</p>

<p>著名录音师史蒂夫 • 阿尔比尼 （Steve Albini) 曾经给一个乐队写过一封信，信中表达了他 对这支即将进入录音棚录音的乐队充满的期待：</p>

<p>“ 我曾经录制过数百张唱片，我清楚地知道录音的结果同乐队录音过程中的情绪有直接 关系。如果录音耗时过长，每个人都很烦躁、指责每个环节……最后的结果很少能让人满 意 。” 0</p>

<p>再著名的录音工作室也无法保证能够录制出好的唱片，再伟大的制片人也不能做出这种保 证。这些因素很重要，但如果录音期间不产出，一切的投入都是徒劳。过程可以提供框架，但
    创意的出现和开发需要灵感和生命力。创造一个积极的、富有成效的组织文化是一个很大的话 题，很难用较短的篇幅完全阐释清楚，但以下组织文化的基本元素却不容忽视，思考一下如何 使用这些元素获得文化火光，激发创造力的火花：</p>

<blockquote>
    • 环境的馈赠 —— 富于创造力的组织可能在环境设计中过于大胆，但有个方法看起来似 乎很疯狂，那就是同人们、艺术品或者建筑之间随意的交互，它为创造力奠定了基调。 小的环境惊喜 ——
    大胆的颜色、新材质、有趣的外表，这些都为创意的激发提供了外 部动力。
</blockquote>
<blockquote>
    • 小的工作场所 —— 理想的工作场所是对创造力友好和善的、有勾画白板和工具并且有 足够空间可以走来走去的地方。没什么比分散注意力更能扼杀创意的了，因此工作场 所应该能够尽量同外部世界隔离幵来。门是实现这一隔绝最典型的方法，但是这一
    方法在开放的工作场所则行不通。遇到难题时，找个角落、竖起屏障，让自己与世界 隔绝。
</blockquote>
<blockquote>
    • 协作的行为准则 —— 团队对于如何开展工作应该达成一致。角色清晰、相互信任、责 任感和工作习惯是最基本的。小的规矩是良好团队协作的基础。会议开始时间、持续
    时间、中场休息和议程看起来无足轻重，但处理不好，小问题会不断积累成大问题。 团队成员必须一起明确设计重点，因此讨论时要关闭手机和电脑。如同厨房洗涤槽里
</blockquote>
<p>® <a href="http://dontpaniconline.com/magazine/music/steve-albinis-letter-to-nirvana-before-heproduced-in-utero">http://dontpaniconline.com/magazine/music/steve-albinis-letter-to-nirvana-before-heproduced-in-utero</a>
</p>

<p align="right" height="0pt" width="0pt">第 6 章创造型团队合作</p>

<blockquote>
    不断积累的灰尘，一个小小的不注意就能轻而易举地毁掉良好的意愿。做好自己本分 的工作，确保自己的团队伙伴承担起自己应该履行的责任。
</blockquote>
<blockquote>
    • 容许积极正面的题外话 —— 题外话看起来不好，但却有可能给你意想不到的灵感。当 团队时间不够，离题被看作是浪费时间和能量。容许题外话的团队倾向于更广泛的讨 论，制定的设计方案也更有趣、更贴心。法则：留点迷路的时间。
</blockquote>
<p>伙伴关系中至关重要的一点就是要留意社会活力。当团队当中存在矛盾时，进展就会迟缓， 质量会下降，设计结果也不会讨喜。对于设计团队来说，解决方案质量不高应该是致命一击。</p>

<p><span id="filepos0000824417"></span></p>

<p><font size="6">确定设计师的技术水平</font></p>

<p>设计师的技术水平必须满足设计问题的广度和深度。技术高手厌倦碰到简单问题•，新手们 则可能碰到自己技术无法解决的细微问题。这两种情形都会让产品受罪，让设计机构的声名蒙
    羞。在实践中，设计领导们必须确保设计师的能力与问题相匹配。这就要求在设计工作开始前 就要对问题的位置、大小和影响有敏锐的观察和感受。</p>

<p>下面为我们如何思考体验的层次和每个层次需要的技巧提供了快速指导。</p>

<blockquote>
    • 学徒 —— 处于设计师早期职业生涯需要跟师傅学习技巧。使学徒做出符合设计任务的 判断还需要大量时间和努力。在成长过程中学徒必须在师傅的指导和支持下解决超出 自己现有层次的问题。
</blockquote>
<blockquote>
    • 技术髙手 —— 随着时间流逝、手艺日益精湛，技术高手们越来越喜欢单打独斗。这使 得他们在核心团队中扮演起领导角色，每天都有新创意、新想法。许多设计者终其一 生停留在这个阶段，尤其当他们不愿承担起组织内领导角色的责任时。
</blockquote>
<blockquote>
    • 领导者们既掌握了高超的设计技术，又有意愿和能力承担领导责任。在大型产品公司 中，设计领导至关重要，他要为设计团队提供指导和架构，鼓吹预算和权威，为项目 确立范围、确定重点，推动设计开发，招聘设计师。
</blockquote>
<p>设计技巧不断进步归结为设计决策的制定。设计师能够多快速地意识到设计方案与任务是 否相配？我们可以多大程度上依靠她引导设计团队做出更好方案或对问题有更深的了解？领导
    们必须有过硬的设计决策技巧、导师技巧和组织头脑。不是每一个设计师都希望培养这些能力， 而领导者也并非技术高手们唯一或最重要的顶级追求。</p>

<p align="right" height="5em" width="0pt">133</p>

<p><span id="filepos0000827514"></span></p>

<p><font size="6">协作是关键</font></p>

<p>创造型理念或优秀设计决策的实现没有捷径。即便你相信自己掌握了正确的理念，也需要 大量辛苦的工作、毅力和技巧来实现它。这当中最具挑战性和复杂但又收获最丰厚的要数与产
    品和商业团队的协作。所有这些挣扎和挑战使我们眼花缭乱，促使我们采取一个有方法的解决</p>

<p>方案。</p>

<p>我们发现设计者应该有能力同项目的其他团队成员开展合作，因为这些人能够对整体的用 户体验产生影响。就项目而言，这包括设计战略制定者、用户和市场研究人员、用户文档编写
    人员、包装设计人员甚至可能包括商店和售货点设计者们。协作是为了确保用户体验的所有方 面能够和谐。设计人员不能怀着多重目的或者使用不同的设计语言进行设计，因为这最终会使 用户感到困惑或使产品信息变得混乱。</p>

<p>最终，能够设计出满足用户需求的产品，并实现成功交付，这个过程需要无数人的悉心合 作。我们发现，设计者必须担负起责任，在无数产品势力的角逐中实现平衡，才能确保方案的
    有效性。我们希望本章描述的各种工具能够帮助你创造出伟大的数字产品，真正满足用户和客</p>

<p>户的需求。</p>

<p>134<br/>
    <br/></p>

<blockquote>
    <font size="7">设计行为和形式</font>
</blockquote>
<blockquote>
    第 <font size="5">7</font> 章良好产品行为的基础 第 <font size="5">8</font> 章数字产品的礼仪 第 <font size="5">9</font> 章平台和姿态 第 <font
        size="5">10</font> 章为中级用户优化设计 第 <font size="5">11</font> 章编配与流 第 <font size="5">12</font> 章减少工作消除负担 第 <font
        size="5">13</font> 章隐喻、习惯用法及能供性 第 <font size="5">14</font> 章重新思考数据输入、存储与检索 第 <font size="5">15</font> 章错误防止通知决策
    第 <font size="5">16</font> 章为不周的需求而设计 第 <font size="5">17</font> 章整合^^觉设计
</blockquote>
<p>/rA* -"" A1!</p>

<p>弟 7 早</p>

<p><span id="filepos0000832197"></span></p>

<p align="right" height="7pt" width="0pt"><font size="7">良好产品行为的基础</font></p>

<blockquote>
    第 1 部分中，我们讨论了如何恰当地定义和设计出令人期待且有效的产品。 但是如何做出这些决定呢？什么成就了好的设计方案呢？正如我们曾经讨论过 的，测量设计质量的一个依据，就是产品满足用户目标和需求的能力，以及是
    否适应商业目标和技术限制。但是产品解决方案是否具有可识别、可实现性的 特征？我们能否将类似问题的解决方案一般化？要成就好的设计是否要求设计 过程具有普遍适用性？
</blockquote>
<blockquote>
    答案就在交互设计价值、原则和模式的使用中。设计价值 （design values) 为成功、恰当的设计实践提供了指导方针。设计原则（ designprinciples )为设计 有用而令人期待的产品、系统和服务提供了向导。设计模式
    （design patterns) 针对某些具体的设计问题给出了一般方案。
</blockquote>
<p><span id="filepos0000834087"></span></p>

<p><font size="6">设计价值</font></p>

<p>设计价值描述有效、合乎道德的设计实践所遵循的规则。这些规则启示并激发了设计的原 则和模型，本章稍后会对二者进行讨论。价值是控制行动的规则，通常基于核心信仰。下列设 计价值由罗伯特 • 莱曼 （Robert Reimann) 、休 •
    达伯利 （Hugn Dubberly) 、金 • 古德温 （Kim Goodwin) 、大卫 • 伏尔 （David Fore) 和乔纳森 • 科尔曼 （Jonathan Korman) 共同开发，适用
    于任何致力于服务人类需求的设计领域，尤其适用于交互设计。</p>

<p align="right" height="0pt" width="0pt">第 7 章良好产品行为的基拙</p>

<blockquote>
    设计师创造的设计方案应该具备以下特点：
</blockquote>
<blockquote>
    • 合乎伦理（有用、贴心）
</blockquote>
<blockquote>
    ■ 不造成伤害
</blockquote>
<blockquote>
    ■ 改善人类环境
</blockquote>
<blockquote>
    • 目标明确（有用、可用）
</blockquote>
<blockquote>
    ■ 帮助用户实现目标和期望
</blockquote>
<blockquote>
    ■ 符合用户场景和能力水平
</blockquote>
<blockquote>
    • 实用（切实可行）
</blockquote>
<blockquote>
    ■ 帮助设计机构实现目标
</blockquote>
<blockquote>
    ■ 满足商业和技术需求
</blockquote>
<blockquote>
    • 优雅（高效、艺术性、能打动人）
</blockquote>
<blockquote>
    ■ 代表最简单而完整的方案
</blockquote>
<blockquote>
    ■ 内在一致性（自我表现、可理解的）
</blockquote>
<blockquote>
    ■ 恰当顺应、调动认知与情感
</blockquote>
<blockquote>
    接下来我们将更详细地探索一下这些价值。
</blockquote>
<p><span id="filepos0000838961"></span></p>

<p>合乎伦理的交互设计</p>

<p>交互设计师对影响人类生活的系统进行设计时，会面临道德问题。这些设计会直接影响产 品的用户，或者会对某种程度上接触到产品的人产生间接影响。对交互设计者来说，这会成为
    一个特别的问题，因为不同于图文设计者，设计工作的产品不单单是与一项政策开展有说服力 的交流或者对某样产品进行市场运作。事实上，设计就是执行政策的方式或者产品创造本身。
    简言之，交互产品是在做事，而作为设计者，我们必须确保我们费尽心力设计出的产品做的是 好事。坦率地讲，产品设计是为用户做好事，但产品对其他人的影响有时很难去估算。</p>

<blockquote>
    不造成伤害
</blockquote>
<p>产品不应该伤害任何人。或者，鉴于现实世界生活的复杂性，产品应该最低限度地减少伤 害。交互系统可能造成的伤害主要集中在以下几个方面：</p>

<blockquote>
    • 人际关系上的伤害（缺乏尊严、侵犯他人、羞辱他们）。
</blockquote>
<blockquote>
    • 心理伤害（困惑、不舒服、烦躁、强迫性、无趣）。
</blockquote>
<blockquote>
    • 身体伤害（疼痛、受伤、残疾、死亡、威胁安全）。
</blockquote>
<blockquote>
    • 经济伤害（减少利润、降低生产力、失去财产或积蓄）。
</blockquote>
<blockquote>
    • 社交和社会伤害（受到剥削或不公正的对待）。
</blockquote>
<blockquote>
    137<br/>
    <br/>
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>• 环境伤害（污染、生物多样性灭绝)。</p>

<p>避免前两类伤害需要对用户有深刻的理解，并且要取得涉众的支持，将这些问题纳入项目 的考虑范畴。第二部分和第三部分讨论的许多概念有助于设计师拟定适合人类智能和情感的解
    决方案。避免身体伤害要求设计师扎实地掌握人体工程学原理，并且合理使用界面元素。身体 伤害的原因可能很简单，比如过多使用鼠标，引起重复性应激损伤。更严重点，不良设计还可
    能导致死亡，比如车内导航系统设计得过于复杂，容易分散注意力。</p>

<p>除了消费型产品，我们很容易想到后三种类型相关的例子，比如股票交易应用、电子投票 系统、离岸石油开釆平台或者核能发电站。</p>

<p>军事或者赌博类应用的设计，或者某种程度上存在蓄意（ deliberately) 伤害他人的应用， 抑或是通过提高劳动力效率降低劳动力数量的应用，都提出困难的挑战，考验设计者的良心 (conscience)
    。对于这种道德灰暗地带很难做出简单的回答。</p>

<p>尽管表面上环境和社会伤害可能看起来跟大部分消费型产品不相关，但细想一下它关乎可 持续性发展问题（ sustainability) 。设计师应该考虑设计产品整个生命周期，包括被人们丢弃之
    后。设计师还应该考虑用户使用产品的行为如何对更广大的环境产生影响。例如，苹果手机及 其相关联的生态系统引起了蜂窝技术和其他网络技术中数据使用的巨大增加。这反过来又促使
    更多蜂窝信号塔的建立，更广阔的服务器群组的扩张和对能源的更大需求。</p>

<p>尽管环境因素在消费型产品的影响中排名第二或第三，并且可能很难做出预估，但是最终 的影响却是很重大的。凯姆 • 劳伦 • 克莱默（ Kem-LaurinKramer) 在《可持续时代中的用户体 验》（ (/^£\:/7^7&gt;«^/«//^^4
    狀 6)/5^ 伽 /«0^// 办）一书中，确定了产品生命周期中与可持续发展 相关的几个关键阶段：</p>

<p>• 制造阶段：产品来源、类型、提取、细化过程及原材料的使用幵始对环境产生影响。</p>

<p>• 运输阶段：产品到市场的运输方式以及相关的能源使用增加了对环境的影响。</p>

<p>• 使用和能源消耗阶段：产品生产、使用和维持服务所耗费的能源增加了对环境的影响。</p>

<p>• 回收阶段：材料的重新利用、维修便利性、升级路径和零部件可更换性也都会对环境 产生影响。</p>

<p>• 设备、环境对产品制造、研发、销售、仓储、服务器群组和其他物理支持路径的要求， 同样对整个环境产生了影响。</p>

<p>以上五个阶段看起来很冗长，设计新产品，尤其是数字产品时需要考虑的东西似乎很多。</p>

<p>但其中只有少数几个真正适用于软件产品，比如传统网络服务的能源消耗和设备等。苹果 等公司就把这些因素考虑在内。苹果最近的许多产品都进行了特别设计，以便尽可能地减少材</p>

<p>138<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 7 章良好产品行为的基础</p>

<p>料的使用、提高废弃材料的回收和降低能源消耗。苹果公司能否将硬件的可持续发展这一前瞻 性方法应用于软件发展或许仍是个有争议的问题，是苹果 、Facebook (Facebook )和整个网络 服务行业需要解决的一个问题。</p>

<p>改善人类处境</p>

<p>当然，真正合乎伦理的设计不仅无害，还应当造福人类。交互系统可以改善以下很多方面 :</p>

<p>• 增进理解（个人、社会及文化)。</p>

<p>• 提高个人与团体的效率或效力。</p>

<p>• 促进个人与团体之间的沟通。</p>

<p>• 降低个人与团体之间的社会文化张力。</p>

<p>• 促进平等（经济、社会及法律）。</p>

<p>• 平衡文化多样性与社会凝聚力。 •</p>

<p>设计师应当始终将以上各类问题牢记在心，时刻考虑有益于人类的设计，哪怕需要打破 常规。</p>

<p><span id="filepos0000849312"></span></p>

<p>目标明确的交互设计</p>

<p>本书的主题是基于用户目标与动机的理解，采取目标明确（ purposeful) 的设计。第一部分 描述的目标导向的开发流程有助于实现这一点。目标明确不仅在于理解用户目标，还在于理解
    他们的局限性，人物模型和用户研究对此很有帮助。观察和交流的行为模式不仅要描述用户的 能力，还应当包括他们的弱点与盲点。目标导向的设计流程帮助设计师创造出弥补缺憾且锦上 添花的产品。</p>

<p><span id="filepos0000850084"></span></p>

<p>实用的交互设计</p>

<p>书架上尘封的设计说明书没有任何用处，设计只有问世才具有价值。一经制造，就需要为 人所用；一经使用，就需要为用户带来好处。在设计过程中考虑商业目标、技术要求与限制条
    件十分重要，这并不是说设计师必须对涉众和程序员言听计从。但商业、工程与设计团队之间 必须进行积极的对话，即产品定义的哪些部分是灵活可变的，哪里有着明确的界限。程序员们
    经常声称某个设计方案无法实现，其实他们的意思是根据目前的进度，该方案无法按时完成。 市场机构可能根据综合的统计数据制定商业计划，而不详细考虑用户个体可能出现的行为。设
    计师收集具体用户的定性研究，对商业模型可能怀有独到的见解。如果设计、商业和工程三个 团队相互信任与尊重，设计工作将顺利得多。</p>

<blockquote>
    139
</blockquote>
<p><span id="filepos0000851615"></span></p>

<p>优雅的交互设计</p>

<p>字典上把优雅同时定义为 “ 形式上的优美和婉约 ” ，以及 “ 科学上的精确和简洁”，我们相 信优雅的设计，或者最起码是交互的设计，实现了二者的完美契合。</p>

<p>代表最简单而完整的设计方案</p>

<p>优秀设计的经典要素之一是形式的简约 （economy of form) ，以简驭繁。对于界面设计，就 是用最少的屏幕与器件来完成任务。简约同样适用于行为，在视觉设计中给予用户简单的工具 ,
    即运用最少的视觉区别明确传达想要表达的意思。对优秀的设计而言，少即是多。解决设计难 题时，设计师应当根据角色的心理模型尽量减少形式与行为的添加。程序员们应当十分熟悉简 约的概念，他们知道好算法往往更简短、更清楚。</p>

<p>著名的户外探险家、户外服饰公司巴塔哥尼亚的创始人依冯 • 肖纳德说得最为贴切，他引 用了法国作家、飞行员安东尼 • 德 • 圣 - 埃克苏佩里的话： “ 完美不在于无以复加，而在于无可 删减，万事莫不如此 。” ®</p>

<p>拥有内在一致性</p>

<p>优秀的设计让人感觉是一个整体，各部分平衡和谐。设计不佳，甚至没有经过设计的产品 看起来像不同零件偶然拼合在一起。这通常是执行架构的产物。不同研发团队开发界面的不同
    模块，彼此缺乏交流，或者硬件与软件分别进行设计。目标导向的开发流程把产品概念作为核 心，通过迭代精确细节为创造内在和谐提供了理想的环境，尤其是场景的应用，确保设计方案 具有统一的叙述主线。</p>

<p>适当顺应、调动认知与情感</p>

<p>许多接受传统培训的设计师常常谈及期待，以及期望对于传达与产品设计的重要性。说得 没错，但我们觉得，如此强调某个单一（模糊且复杂）的情绪，有时会导致一叶障目。</p>

<p>产品设计过程中，假如目标明确，或者高度技术化、专业化，则期望只是我们追求的一小 部分情感。谁指望让操作放疗系统的技师喜欢她的设备呢？相反，我们希望她能够对设备潜在的
    危险能心怀畏惧，小心谨慎。因此，作为设计师，我们竭尽全力地将操作者的注意力放在治疗和 病人身上。较之期望，笔者认为优雅意味着在任何情况下适当地顺应、调动用户的认知与情感。</p>

<p>本书后面的章节中列举了我们认为最重要的交互设计与视觉设计原则。这些作为入门知识</p>

<p>① Saint-Exup 泛ry，2002</p>

<p align="right" height="0pt" width="0pt">第 7 章良好产品行为的基础</p>

<p>足矣。在第一部分中，我们己经介绍了目标导向交互设计工作背后的流程与概念。接下来，我 们将提出若干有益的设计见解，帮助你将知识转化为各个领域的精彩设计。</p>

<p><span id="filepos0000856463"></span></p>

<p><font size="6">交互设计原则</font></p>

<p>交互设计原则是关于行为、形式与内容的普遍适用法则，促使产品行为支持用户目标与需 求，创建积极的用户体验。这些原则，能够解决行为、形式和内容方面的设计问题。事实上，
    这些原则也是一些设计中需要遵循的规则，以设计师价值和体验为基础，其核心价值在于秉承 科技应当服务于人类智慧和想象这一理念。科技的使用体验应当根据人类的感知、认知与运动 能力来创造。</p>

<p>原则要贯穿设计全过程，帮助我们将情境中的任务和需求转化为界面的形式结构和行为。</p>

<p align="right" height="2em" width="0pt">作用于不同层面细节的原则</p>

<p>设计原则作用于不同的层面，上至普遍的设计规则，下至交互设计的细节。不同层面之间 的界限不是很分明，但大体可以归为以下几类：</p>

<blockquote>
    • 概念原则：用来界定产品定义，产品如何融入广泛的使用情境。第 8 章至第 13 章讨 论概念层面的设计原则。
</blockquote>
<blockquote>
    • 行为原则：描述产品在一般情境与特殊情境中应有的行为，第 14 章至第 17 章将探讨 行为层面的普遍设计原则。
</blockquote>
<blockquote>
    • 界面原则：描述行为及信息有效的视觉传达策略，第 18 章至第 21 章关注这一层面的 交互设计原则。
</blockquote>
<p>大多数的交互设计与视觉设计原则是跨平台的。但是对于类似移动设备和嵌入式系统这样 的产品，由于屏幕面积、输入方式及使用情境等因素的制约需要特殊考虑。</p>

<p align="right" height="1em" width="0pt">行为与界面层面的设计原则使工作负荷降至最低</p>

<p>设计原则的主要目的之一就是优化用户的产品体验。对于生产工具和其他非娱乐导向的产 品而言，这意味着将工作负荷降至最低 （minimizing work )。</p>

<p align="right" height="6pt" width="0pt">本书描述的大多数原则旨在减少工作负荷，同时为用户提供更多层面的反馈和有用的情境 信息。第 12
    章主要描述需要最大限度降低负荷的不同工作类型，以及实现这一目标的具体战略。</p>

<blockquote>
    141<br/>
    <br/>
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>游戏和其他类似娱乐产品则需要在某种程度上以不同的方式降低工作负荷，而不是简单地 减少工作量。他们可以要求用户完成一定量的工作然后给予相应奖励。譬如开心农场之类的社
    交游戏之所以火爆，是因为人们逐渐沉迷于要完成的任务，为照料自己的虚拟农场（以及同其 他人分享成功的骄傲感）而乐此不疲。当然，过多的任务或者太少的奖励都有可能使游戏变得 乏味。此类交互设计需要把握得当。</p>

<p><span id="filepos0000861578"></span></p>

<p><font size="6">交互设计模式</font></p>

<p>设计模式是捕捉有效设计方案并将其应用于类似问题的方法，尝试将设计理论形式化，记 录最好的实践工作，有助于实现以下目标：</p>

<p>• 节省新项目的设计时间和精力。</p>

<p>• 提高设计方案的质量。</p>

<p>• 促进设计师与程序员的沟通。</p>

<p>• 帮助设计师成长。</p>

<p>尽管在设计教育和提高工作效率方面，模式的重要性不言而喻，但交互设计的模式发展却 尤其令人兴奋；因为它们代表了用户体验和相关活动的优化成果。</p>

<p><span id="filepos0000862829"></span></p>

<p>建筑模式和交互设计</p>

<p>交互设计的模式理念源自克里斯特福 • 亚历山大 （Christopher Alexander ),他撰写了两本 具有巨大影响力的著作，即《模式语言 》(Oxford University Press, 1977)
    和《永恒的建筑方式》（ 77^ （Oxford University Press, 1979 )。书中首</p>

<p>次描述了建筑设计模式这一概念。通过对建筑特征的一系列精确定义，亚历山大试图描述那些 带给居民幸福感的建筑设计的精华。</p>

<p>亚历山大同交互设计师的最终目的十分相近，每一个模式对于人的关注使得建筑模式和交 互设计模式及工程模式有所区别。后者的主要目的是实现程序代码的重复利用和标准化。</p>

<p>而交互设计模式和建筑设计模式有一个重要的区别，交互设计模式不仅关注结构和元素组 织，还关注相应用户活动的动态行为与变化。简单地把它理解为随时间而变化听起来不错，但
    这些变化的趣味在于它们对软件状态和人类活动都会产生反应，因此与机械和电视及影片那种 预定的时程变化有所不同（它们都有各自独特的设计模式）。</p>

<p>142</p>

<p><span id="filepos0000864954"></span></p>

<p><u>记录和使</u> 用 <u>交互设计模式</u></p>

<p>模式总是应用于特定情境，它们适用于具有类似情境、限制、张力和拉力的设计场景。提 取一个模式，重要的是记录方案应用情境的一个或多个具体案例、所有案例共有的特征，以及 解决方案背后的理念（它好在哪里）。</p>

<p>为了达到使用效果，模式必须根据应用场景进行有条理的组织。这种模式通常称为“模式 库 ” 或者 “ 类目表 ” （ catalog )。如果类目表定义精确，并且充分涵盖了某个领域所有的解决方 案，就能提升为一种模式语言 （pattern
    language )。（考虑到数字产品的创新速度，这样的语言 很难稳定。）</p>

<p>设计模式的运用，没有捷径，也没有立竿见影的解决方案。《设计交互界面》</p>

<p>/« 纪响 cm) — 书广泛收集了各种交互设计模式，作者珍妮弗•泰德维尔曾在书中发出这样的警 告： “ 模式不是拿来就能用的商品，每一次模式的运用都有所不同 。” ®</p>

<p>在软件设计领域，有一种观点很具有吸引力，即如果用户需求清晰，一套全面的模式类目 表可以帮助设计新手迅速且轻松地整合出协调的设计方案。虽然我们发现，这一想法在一些资
    深设计师身上的确适用，但模式永远不能脱离应用背景而像饼干模具那样机械地拼凑使用。克 里斯特福 • 亚历山大随即指出，情境在模式表现形式上具有决定性作用，因此，建筑模式是预
    制建筑的对立面。模式展开的环境极其重要，它的子模式、母模式，以及相近的其他模式同样 十分关键，交互设计模式同样如此。每个模式的核心在于表现对象之间，以及对象与用户目标
    之间的关系（这就是为何一个概括的风格说明无法代替具体的设计方案的原因）。模式的精确形 式在每一个设计方案中都会有或多或少的差别，定义模式的对象自然因产品领域的不同而不同， 但对象之间的关系基本保持一致。</p>

<p><span id="filepos0000868238"></span></p>

<p>交互设计模式的类型</p>

<p>与许多其他设计模式类似，交互设计模式也可以有层次地组织在一起，从系统层面到个别 界面的专用器件。与原则一样，模式可以应用于系统的各个层面（这些层面之间的界限同样十 分模糊）。</p>

<p>定位模式应用于概念层面，帮助界定产品对于用户的整体定位。定位模式的实例之一就是 “ 暂态 ” ，即使用很短的时间服务于一个在别处实现的高级目标。产品定位的概念及最显著的模 式都将在第 9 章中进行详细讨论。</p>

<p>① Tidwell, 2006</p>

<blockquote>
    143<br/>
    <br/>
</blockquote>
<p><img class="responsive-img" align="baseline" alt=""  src="../Images/Image00279.jpg"/></p>

<p>结构模式解答如何在屏幕上安排信息和功能元素之类的问题。尤其是随着 i 〇 S 和安卓等移 动用户界面和平台的广泛使用，结构模式越来越多地被记录下来。它包括视图、窗格，以及元 素组合等，这些我们在第三部分中略有讨论。</p>

<p>行为模式旨在解决功能或数据元素的具体交互问题，大多数人所说的器件行为即属于此。 还有很多类似的低层次模式，也在第三部分中有所讨论。</p>

<p>对于交互设计师来说，构建心理模式类目表是至关重要的一项培训内容。当我们逐渐了解 到彼此工作的精华部分，我们就能够一道努力为用户提供更好的交互用语。通过利用现有工作 , 我们能够专注于解决新的问题，而避免重蹈覆辙。</p>

<p><span id="filepos0000871270"></span></p>

<p>交互设计模式示例</p>

<blockquote>
    以下章节主要描述几个交互设计模式，其他详细内容参见本书第三部分内容。
</blockquote>
<blockquote>
    桌面：组织者-工作区
</blockquote>
<p>最常用的高级结构模式之一即微软的 Outlook 界面，导航窗格在左边，工作区在右方，总 览窗格位于上方，详情窗格位于下方（见图 7-1 )。</p>

<blockquote>
    UMf/unintm
</blockquote>
<blockquote>
    <font size="1">MM</font> mt/il tl 11 m
</blockquote>
<blockquote>
    MM M «M M MM f a»/ll UM _
</blockquote>
<blockquote>
    <font size="2">■</font> 祖祖 <font size="2">&gt;^</font> 山顧-麵
</blockquote>
<blockquote>
    o
</blockquote>
<p>□</p>

<blockquote>
    <font size="2">图</font> 7-1 <font size="2">微软公司</font> Outlook <font size="2">的基本结构模式在整个行业应用广泛，横跨多种不同的产品。左侧垂直窗格提供导航，驱动
    右上角的内容总览。选择总览窗格中的对象，右下窗格中出现相应的细节或文件内容。</font>
</blockquote>
<p>144<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 7 章良好产品行为的基础</p>

<p>该模式适用于全屏软件。用户需要访问多种不同种类的对象，通过按组操作显示个别对象 及文件的具体内容或属性，该模式确保上述操作在单一窗口中顺畅完成。许多电子邮件的客户
    端都采用了这种模式。不少写作和信息管理工具，因为经常需要迅速获取和处理各种对象，也 使用了这种模式的变体。</p>

<p>智能手机.•双层抽屉</p>

<p>以 Facebook 和 Path 手机 App 作为先驱者，首先使用新的功能，即通过向左滑动主界面展 示右侧界面，向右滑动主界面显示左侧界面。这一功能在 i 〇 S 和安卓系统的许多应用中都很常
    见。通常左侧抽屉包含手机应用的主要导航，而右侧抽屉通常用来进入某个软件的辅助列单（比 如 Facebook 中的朋友名单）。</p>

<p align="center" height="0pt" width="0pt"><img class="responsive-img" align="baseline" alt=""  src="../Images/Image00214.jpg"/></p>

<p>图7-2 Facebook双层抽屉则属子另一种结构模式，正如组织者-工作区对于桌面应用一样，双层抽屉也成为移动手机 普遍使用的模式之一。左边的抽屉提供了导航，显示应用的内容。右边的窗格则提供了快速进入其他应用的快捷键，比
    如Facebook的朋友圈。</p>

<p><br/>
    <br/></p>

<p>同组织者 - 工作区模式一样，双层抽屉在内容上实现了完美的优化，这样的话可以实现移动 而不是桌面操作。通过滑动主界面窗格显示导航或者通信部件是一种简单的操作，一只手足以
    操作。从开放的抽屉里进行选择也是一种用拇指即可进行的简单操作。抽屉的类似开关也符合 审美要求。不怪乎这种模式能够迅速并广泛地拓展开来。</p>

<blockquote>
    145
</blockquote>
<p><span id="filepos0000878125"></span></p>

<p align="right" height="0pt" width="0pt"><font size="7">数字产品的礼仪</font></p>

<blockquote>
    在《媒介等同 》（) — 书中，斯坦福的两位社会学家克 利福德 • 纳斯 （Clifford Nass ) 和拜伦 • 里夫斯 （Byron Reeves )在一个令人信
    服的案例中发现，人类与计算机及其他交互产品之间的对待和反应方式如同人 与人之间的交往。因此，我们应该充分重视数字产品的人物模型和性格：它们 是否有足够的竞争力？是否有用？是否会抱怨、焦虑、纠缠不休或者找借口？
</blockquote>
<blockquote>
    纳斯和里夫斯研究发现，人类好像有一种本能，告诉他们如何与周围有意 识的生物交往。一旦可物体表现出足够的交互性——就像一般的软件程序那 样 —— 这些本能就会激活。我们与软件的交互也出于本能，是无意识行为，也 是不可回避的。
</blockquote>
<blockquote>
    这个研究的意义是深远的，如果希望用户喜欢我们的软件，那么当我们设 计软件时，应该让它表现得像一位举止得体的人。如果希望用户能高效地使用 我们的软件，那么就应该将它设计得像一个帮助和支持自己工作的同事。一句
    话，应当考虑人与计算机在工作上的角色分配。
</blockquote>
<blockquote>
    ■原则
</blockquote>
<blockquote>
    人来思考，计算机干活。
</blockquote>
<p align="right" height="1em" width="0pt">理想的人机分工是很明确的，计算机就是用来做事情的，而人是考虑如何做事情的。科幻 小说家和计算机科学家总是用人工智能来迷惑我们 ——
    计算机可以自我思考。然而，人类恰恰</p>

<p align="right" height="2em" width="0pt">第 8 章数字产品的礼仪</p>

<p>不需要思考方面的帮助——我们人类识别模式和解决复杂问题的能力是任何一个电子芯片产品 无法媲美的。我们需要的是在信息管理上的帮助，比如访问、分析、组织以及将信息形象化等
    工作，而根据这些信息来做决策，最好由我们自己，即大脑来完成。</p>

<p><span id="filepos0000882266"></span></p>

<p><font size="6">设计体贴的软件</font></p>

<p>纳斯和里夫斯认为，软件应该是礼貌的，但是我们更喜欢用 “ 体贴的 ” 这个词来形容。尽 管礼貌可以解释为一种礼节，如 “ 请 ” 、 “ 谢谢 ” 等，但其他有用的方面我们做得还不够，真正
    的体贴意味着心里始终想着他人的需求。体贴的软件最关心的是用户的目标和需求，其次才是 其基本功能。</p>

<p>如果软件缺乏信息，过程模糊，迫使用户到处寻找常用的功能，还因为软件自己的问题责 备用户，那么这种软件就是低效的，用户体验不到愉快。即便软件多么有礼貌，多么有代表性 , 视觉隐喻多么好，内容多么充实或者多么拟人化，也是如此。</p>

<p>此外，如果交互是谦让的、大方的，对人有所帮助，那么就会对用户产生长期的正面影响。</p>

<blockquote>
    <font size="7">&nbsp; <sub>
        <small><font size="7"><font color="#000000">0</font></font></small>
    </sub></font>
</blockquote>
<blockquote>
    设计原则
</blockquote>
<blockquote>
    软件应该像人一样体贴。
</blockquote>
<p>通常，具有交互性质的产品惹怒我们的不是它们缺少哪些功能，而是不体贴。其实，做一 个体贴的产品不比做一个粗陋的产品难多少，你只需要想象一个关心他人的人士是如何与别人
    打交道的，效仿他就可以了。这些体贴的特征没有一个是和功能至上的数据处理的目标相违背 的，这些数据处理都是针对含有电子芯片的产品来说的。事实上，产品表现得越有人情味，就
    越符合实用这个目的。如果这些富有人情味的特征适当地组织在一起，那么与用户间的对话便 利于有效地使用软件的功能。</p>

<p>人有许多特征，让自己变得体贴。人们或多或少地也将这些特征赋予了具有交互性质的产 品，以下列举了一些体贴的交互性质的软件产品 /( 和人）所具有的特点。</p>

<p>• 体贴的软件关心用户喜好。</p>

<p>• 体贴的软件是恭顺的。</p>

<p>• 体贴的软件是乐于助人的。</p>

<p>• 体贴的软件具有常识。</p>

<p>• 体贴的软件有判断力。</p>

<p align="right" height="2em" width="0pt">147</p>

<p>• 体贴的软件预见需求。</p>

<p>• 体贴的软件是尽责的。</p>

<p>• 体贴的软件不会因为自己的问题增加你的负担。</p>

<p>• 体贴的软件会及时通知我们。</p>

<p>• 体贴的软件是敏锐的。</p>

<p>• 体贴的软件是自信的。</p>

<p>• 体贴的软件不问过多的问题。</p>

<p>• 体贴的软件即使失败也不失风度。</p>

<p>• 体贴的软件知道什么时候调整规则。</p>

<p>• 体贴的软件承担责任。</p>

<p>• 体贴的软件能够帮助你避免犯低级错误。</p>

<p>顺便说一下，以上特点与更加实用的功能数据处理过程（这是所有数字产品设计的核心 ) 的目标一致，没有任何矛盾的地方。接下来我们将对以上特点进行详细阐述。</p>

<p><span id="filepos0000888724"></span></p>

<p>体贴的产品关心用户喜好</p>

<p>体贴的朋友希望加深对你的了解。他记得你的喜好，知道如何使你开心。每个人都希望得 到个性化的体贴和照顾。</p>

<p>然而另一方面，大多数软件不知道也不关心自己的用户是谁。尽管我们一直在反复使用个 人计算机中的软件，但它们好像也不记得关于我们个人的一些信息。举一个优秀的软件行为的
    例子，火狐或者微软上网浏览器能够记住用户定期登录网站的相关信息，比如用户名和收件地 址。谷歌浏览器甚至能记住不同设备和会话的小细节。</p>

<p>软件应该努力记住我们的小习惯，尤其是我们告诉过它的事。对于编写程序的开发人员来 说，从用户那里收集信息和从数据库里收集信息一样，是理所当然的。所以当程序需要信息时 ,
    就让用户提供。用完了之后，程序就将这些信息扔掉。等下次再需要时，就再询问用户。程序 本来就比人更适合记忆信息，然而到头来，它却忘了这些信息，这就太不体贴用户了。记住用
    户的行为和偏好，是最好的方法了，它能对用户使用软件产生积极作用。我们将在这一章的后 半部分详细讨论软件记忆这个问题。</p>

<p><span id="filepos0000890401"></span></p>

<p>体贴的软件是恭顺的</p>

<p>一个好的服务员是客户至上的，她明白正在接受服务的人就是老板。当餐馆服务员将我们 带到一张桌子面前时，我们会认为他选择的座位只是一种建议，而不是命令。在人少的餐馆，</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>我们如果礼貌地要求换另一个座位时，我们希望服务员接受我们的要求。如果餐馆服务员拒绝 了我们的要求，我们可能就会选择另一家更尊重我们意愿的餐馆。</p>

<p>不体贴的软件监督并随意判断人的行动，当然软件可以认为我们犯了错。但是它随意判断 或者限制我们的行为，就显得太不体贴了。在我们输入自己的电话号码之前，软件可以建议我
    们暂时不要提交，并解释原因。但如果我们坚持没有号码时也要提交，那么希望软件能够按照 我们的意愿做。 “ 提交 ” 这个词和它所代表的含义，有悖于软件应该扮演的恭顺角色。软件应该 向用户提交，任何提供 “ 提交 ”
    按钮的程序都是不礼貌的，是有歧义、让人困惑的。</p>

<p><span id="filepos0000892285"></span></p>

<p align="right" height="2em" width="0pt">体贴的软件是乐于助人的</p>

<p align="right" height="1em" width="0pt">如果向商店服务员询问在哪里可以找到某件商品，我们希望他不仅能回答我们的问题，还
    能主动向我们提供一些其他有用的信息，比如花差不多的价钱可以买到某种性价比更高的商品。</p>

<p>多数软件不会尝试提供其他相关信息；相反，它只是狭隘地回答我们问它的问题。即使是 与我们的目标明确相关的其他信息，它也不愿提供。当我们告诉文字处理器打印一份文档时， 它不会告诉我们打印纸不够了，也不会告诉我们前面有 40
    份文档在排队等待打印，或附近另一 台打印机空闲，而一个乐于助人的人会告诉我们这些信息。</p>

<p>给用户提供有用的信息，需要一个合适的途径，微软的剪贴小助手（ Clippy) —直以来因 为其自以为是的帮助而受到普遍的歧视。比如 “ 你似乎正在打印一封信，需要帮助吗？ ”虽然
    我们很赞赏这种热心帮助的好意，但我们不需要其帮助时，希望它不要那么鲁莽，能够领会我 们的暗示。毕竟一个好的服务员不会打断客人讲话而去询问是否需要加水，而是当杯子空了以
    后，就会给你倒上。他总是可以对你的暗示心领神会，而不是通过询问得到答案。</p>

<p><span id="filepos0000894176"></span></p>

<p align="right" height="2em" width="0pt">体贴的软件具有常识</p>

<p>在不合适的地方提供不合适的功能是交互产品设计失败的一大标志。多数交互产品将经常 使用的控件和从不使用的控件放在一起，你很容易发现菜单中，简单、无害功能与不可撤销的类 似 “ 弹射座椅控制杆 ”
    等专业级的功能紧邻在一起，这就像坐在打开的烤肉炉边上的感觉一样。</p>

<p>一些可怕而让人恼怒的事是计算机系统反复地给用户发送金额为 0 的支票，或数字为 957 ， 142,039.58 美元的账单。我们认为此类事情发生，尤其是频繁发生时，系统应该提醒收账或
    付账部门人员，但大多数信息系统很少能有这种常识。</p>

<p align="right" height="4em" width="0pt">149</p>

<p><u>体贴的软件有判断力</u></p>

<p>一般来说，我们希望软件能够记住我们的操作和指令。但也有一些信息，比如密码、纳税 人号码、银行账号和密码等，我们不希望在没有接受用户指令的情况下自动记录。相反，我们
    希望软件能够帮助我们保护此类个人隐私数据，比如选择安全的密码，及时报告不当的操作， 类似于账户正在陌生电脑或地址上登录。</p>

<p><span id="filepos0000896271"></span></p>

<p>体贴的软件预见需求</p>

<p>当你前往一个陌生城市旅行，你的助手能够在你没有提出任何要求时，主动帮你预定你所 需要和喜欢的旅馆，说明她能够预见你的需求。</p>

<p>当我们仔细浏览网页时，网络浏览器浪费大量的时间闲置着，什么也不做。其实它可以在 我们阅读时，轻松预测我们的需求并做好准备，也可以利用这些闲散的时间提前下载所有可见
    的链接。当我们要求浏览器检测一个或多个链接，它能够立即进入相应界面。要知道关闭一个 不想要的请求很容易，但等待请求加载却很浪费时间。我们将在后半部分进一步讨论如何利用 软件的空闲时间为我们办事。</p>

<p><span id="filepos0000897258"></span></p>

<p>体贴的软件是尽责的</p>

<p>一个尽责的人会从长远的角度来认识所执行任务的意义。例如，一个尽责的人会擦干净柜 台，倒空垃圾，而不只是洗刷盘子，因为那些事情与清洁厨房这个更大的目标有关。一个尽责
    的人在起草报告时，还会在报告上加一个漂亮的封面，并为整个部门影印足够的份数。</p>

<p>举个例子，假设我们有一个助手叫罗德尼，我们让他把一个名为马尼拉的文件夹整理好。 他检查了文件夹标签上的名字，比如说微晶石公司合同，然后在文件库里寻找。在 M 条目下，
    让他吃惊的是其中也含有一个同样的微晶石合同标签的马尼拉文件夹。罗德尼注意到它们之间 的差别并进行研究。他发现先前的文件夹包含一份关于 17 个机械小部件的合同，这些机械小部 件 4
    个月前已经交付到微晶石公司；另一方面，新文件夹是有关下个季度生产和交付 32 个齿轮 部件的合同。有责任心的罗德尼将老的文件夹改名为 2013 年 7 月份微晶石小部件合同，然后将 新文件夹改名为 2013 年 11
    月份微晶石齿轮合同。这种主动做事的态度让我们觉得罗德尼很有 责任心。</p>

<p>假设我们之前有个助手叫艾略特，他完全是个傻瓜，一点都不负责任。如果他遇到相同的 情况，就会不假思索地将新的微晶石合同文件堆到旧的微晶石合同旁边。诚然，他也完成了任
    务，但他原本可以做得更好，让我们将来查找该文件更方便。这也是我们为什么不想让艾略特</p>

<p>150</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>当助手的原因。</p>

<p>如果我们依靠文字处理软件草拟一份新的齿轮合同，然后想把它保存在微晶石目录下。程 序提供的选择是要么毁掉原先的小部件合同重新拟定新合同，要么就根本不能保存。程序不仅
    没有罗德尼能干，甚至还不如艾略特，他比傻瓜还愚蠢。软件如此笨拙，以至于仅仅因为文件 的名字相同，就认为我们要把旧的文件扔掉。</p>

<p>最起码，程序应该将两个文件标上不同的日期，然后保存。即使程序拒绝单方面采取这种 极端的行为，它至少应该在保存新文件之前，向我们显示旧文件，请我们重新命名该文件。程 序完全可以采取更多负责任的行为。</p>

<p>体贴的软件不会因为自己的问题增加你的负担</p>

<p>在服务台前，人们总是希望服务员能够充分照顾自己的关注点，而不是她滔滔不绝地介绍 她所关心的问题。也许这对他们来说有失公平，但这就是服务业的规则。交互产品也应该对自
    己的问题保持沉默，关注用户的需求。由于电脑没有自我意识或者敏感脆弱的情感，它们更应 该胜任这种角色，然而事实正好相反。</p>

<p>交互产品总是用错误信息提示向我们抱怨，用确认对话框打断我们，用一些不必要的通知 向我们炫耀（文档保存成功！软件先生，你太好了，你有过保存失败的时候吗）。我们对程序是
    否有信心清空垃圾箱不感兴趣，我们不想听到软件抱怨不知道将文件保存到磁盘哪个位置。我 们也不需要看到电脑的数据传输率和它的加载顺序，就像我们不需要知道客服代表不愉快的情
    感经历一样。软件不仅要对自己的事情保持沉默，还应该更聪明、自信并自主地解决自己的问 题。我们将在第 15 章中详细地讨论这些问题。</p>

<p>体贴的软件会及时通知我们</p>

<p>虽然我们不希望交互产品因为小小的恐惧和成功不断纠缠我们，但我们却真心希望它能够 及时通知我们所关心的事情。我们不希望酒吧招待向我们抱怨他最近离婚了，但我们会感谢他
    能在明显的地方标明酒类价格，在黑板上写明何时举行赛前晚会、谁将出场，以及当前的活动。 获得这些信息时，没有人打断我们。无论何时，这些信息都在那里。同样，软件可以为我们提 供大量运行状态的非模态反馈，这点我们将在第 15
    章中谈到。</p>

<p><span id="filepos0000903318"></span></p>

<p>体贴的软件是敏锐的</p>

<p>现在大多数软件都不怎么敏锐，它们对多数问题的理解是狭隘的。它也许愿意执行艰难的</p>

<p>任务，但这只是在正确的时间接收到准确的指令时才会这么做。比如，如果你请库存查询系统 告诉你有多少小部件，它会忠实地查询数据库，并报告你截至目前库存的数量。但是，如果 20
    分钟后，达拉斯分公司的人将库存的所有小部件都清走了，情况又会如何呢？当你的电脑傻在 那里，运算着 10 亿次无用指令时，你的操作就有可能引起大麻烦，它完全没有意识到这些问题。
    当你查询过一次小部件的数量，难道这不意味着你很有可能会再次查询这一信息吗？虽然你不 希望以后每一天都收到小部件库存情况的报告，但很有可能在査询后的一星期内你是希望看到
    这些信息的。敏锐的软件能够察觉用户的操作，并利用这些观察为用户提供相关的信息。</p>

<p>软件也应该观察我们的偏好，并且主动记录下来。如果我们总是将一个程序的屏幕设置为 最大化，程序在几次之后就应该将这一模式设定为默认设置。对于调色板、默认工具、经常使 用的模板设置和其他有用的设置也应该如此。</p>

<p><span id="filepos0000905114"></span></p>

<p>体贴的软件是自信的</p>

<p>交互产品应该坚定自己的信念，如果我们命令电脑删除一个文件，它不应该问“确定删除 该文件吗？ ” 我们当然确定，否则也不会提出这一请求，他不应该怀疑我们或自己。</p>

<p>另一方面，如果计算机怀疑我们可能出错（这也是常事 ) ，它应该做好准备恢复已删除的文件。</p>

<p>多少次，你点击完打印键后去喝杯咖啡，等你回来时却发现一个可怕的对话框在屏幕中央 抖动： “ 你确定要打印吗？ ” 这种不安全感简直令人抓狂，它完全违背了体贴这一原则。</p>

<p>体贴的软件不问过多的问题</p>

<p>不体贴的软件总是问许多烦人的问题。过多的选择很快就让它丧失了优势，反而成了一种 痛苦的经历。</p>

<p>问问题与提供选择完全是两码事。当你一个人在商店里逛时，你会有很多选择。当你参加 工作面试时，面试官会询问你很多问题。这两个体验哪个更舒服呢？部分原因在于我们都明白
    提问题的人所处的位置要比被提问的人更优越，有权威的人提问，级别或职位稍低的人回答问 题。当软件提问而不是提供选择时，用户会产生类似的胁迫感。</p>

<p>除了权力导致的这种结果，问题也会让人感觉受到烦扰和侵犯。你喜欢汤还是沙拉？沙拉。 你喜欢卷心菜还是菠菜？菠菜。你喜欢法式、千岛还是意式沙拉酱？法式。你想要清淡点还是
    正常放盐量？够了，还是请你给我来一份汤吧！你想要玉米浓汤还是鸡肉面汤？</p>

<p>用户不喜欢产品问问题，尤其是一些愚蠢或不必要的问题。产品问问题会让用户觉得产品：</p>

<p>152</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>• 无知。</p>

<p>• 健忘。</p>

<p>• 软弱。</p>

<p>• 烦躁不安。</p>

<p>• 缺少主动性。</p>

<p>參要求过多。</p>

<p>这些正是我们在人际交往中讨厌的毛病，又怎么会希望产品有这些特点呢？交互产品的应 用程序不是像朋友在餐桌边上聊天一样，用好奇或者想聊天的方式询问问题，而是表现得很无
    知，同时还夹带着不该有的权威感问问题。它对我们的想法不感兴趣，只是需要得到一种信息， 而通常这些信息压根儿就没必要询问我们。</p>

<p>许多自动取款机一直询问用户选择哪种语言： “ 西班牙语、英语还是中文？”用户第一次做 出选择后，以后使用时也不可能再改变答案。问题少的交互产品，不会询问问题而是会提供选
    择，并且能够记住用户的信息；这样的产品对用户来说更聪明，也更礼貌和贴心。</p>

<p>体贴的软件即使失败也不失风度</p>

<p>当你的朋友很没礼貌时，他会试图弥补，尽可能挽回损失。当程序发现一个致命问题时， 它可以充分利用时间，努力弥补过失而不让用户受到损害，或者简单点让系统直接崩溃。</p>

<p>许多应用程序包含大量的数据和设置，一旦崩溃，信息就丢失了，而用户只能自认倒霉。 比如说，程序运行良好，正从服务器下载电子邮件，此时内部子程序内存已满。和多数桌面软 件一样，程序发出一个有效消息： “ 你的程序完全瘫痪了 ”
    ，在单击确定按钮后程序会立即结束。 当你重新启动程序，或者重启电脑时，却发现电子邮件内容丢失了。当你向服务器查询时，又 发现它已经删除了你的邮件，因为邮件已经移交给了程序，这不是我们所希望的好软件应该出 现的情况。</p>

<p>在电子邮件的例子中，程序接收到服务器的电子邮件后立即删除了邮件副本，却没有确保 电子邮件会自动记录下来。如果邮件程序先确保那些邮件写进了本地磁盘，然后通知服务器已 经成功下载那些邮件，就不会出现这种问题。</p>

<p>有些优秀的设计软件，可以利用撤销缓冲从崩溃中恢复，比如专业音乐制作软件 Ableton Live 。这是一个产品轻松追踪用户行为的极佳例子，这样即使有些情况下出了问题，还是可以 轻松地从困境中解脱。</p>

<p>即使程序没有崩溃，不体贴的行为也是很常见的。尤其是在网上，这种问题更加明显。用</p>

<blockquote>
    153<br/>
    <br/>
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>户经常需要在网页的一系列表单中输入详细信息。在填完 10 个或 11 个字段之后，用户可能单 击提交按钮，但由于这部分输入有错误或者遗失，站点拒绝其输入并提示纠正。于是用户单击
    返回箭头回到页面，发现那些正确的输入连同那些无效的输入一起都被删除了。还记得那个不 可理喻的可恶的初中地理老师吗？他把你那篇南美洲的报告全部撕成碎片然后扔掉，只因为你
    是用铅笔而不是钢笔写的。直到今天，你还因此讨厌地理吧。不要创造类似的产品！</p>

<p>体贴的软件知道什么时候调整规则</p>

<p>在人工信息处理系统被转化为计算机系统的过程中，一些东西丢失了。尽管一个自动订单 输入系统可以处理上百万次的订单，比人类员工能处理的要多得多；但人类能够以某种多数自 动系统忽略的方式工作，而在自动系统中几乎没有利用这种功能。</p>

<p>在人工系统中，当销售部的员工告诉职员加速处理某个订单意味着更多生意的时候，他就 可以迅速处理那个订单；当另一个订单缺失一些关键信息时，他也可以继续处理并记得随后要 补充和记录这些信息：这种灵活性是自动系统所缺乏的。</p>

<p>多数计算机系统只有两种状态，即不存在或者全部一致，无法识别或接受任何中间状态。 在任何手工系统中，有一个重要但矛盾的状态 —— 尽管没有被说出，也没有记载，但又非常可
    靠，即暂停状态。这一状态中，尽管交易没有全部处理完毕也能被接受。操作员在头脑中、书 桌上或者口袋里创建了这种状态。</p>

<p>举个例子，数字系统在保存发票之前需要客户和订单信息，而员工则可以在得到客户的详 细信息之前直接提前登记订单；即计算机系统会拒绝这笔交易，因为没有详细的客户信息就不 允许开发票。</p>

<p>在人工操作系统中，人们会打破操作顺序，或在满足先决条件之前就执行操作，这称为“规 避能力 ” （ ftidgeability) 。这是计算机系统的缺失之一，这种缺失是数字系统缺乏人性的一个关
    键因素，这是实现模型的自然结果。开发人员没有看到任何创建中间状态的理由，因为计算机 不需要，但人类对于轻微调整系统却有着强烈需求。</p>

<p>可规避系统的一个好处是减少错误。通过允许小的临时错误进入系统并授权人们可以在造 成严重问题之前纠正它们，从而避免更大以及更永久性的错误。矛盾的是，大多数计算机加强
    硬性规则正是为了防止类似错误的出现。这些死板的规则将软件和人类对立起来。因为人类拒 绝采取规避措施来防止更大的错误，因此很快就对软件的保护措施失去兴趣，也就无法避免真
    正的大问题。当死板的规则强加在灵活的人类身上时，两面皆输。从商业上说，阻止人们做他 们想做的事总是不好的，而计算机系统也不得不经常消化无效的数据。</p>

<p>154<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>在现实世界中，缺失的信息和没有适当填充到标准字段的额外信息都是成功的重要工具。 如果截止日期比计划期限延长两星期，某个交易才能完成，多数公司宁愿延长计划期限，也不
    愿看到一个上百万美元的交易化为泡影。在现实世界中，限制总是可以调整的，体贴的软件需 要意识到并且包容这类事实。</p>

<p><span id="filepos0000917728"></span></p>

<p>体贴的软件承担责任</p>

<p>大多数软件面临问题时，会釆取这种态度： “ 这不是我的责任。 ” 当工作任务暂时告一段落， 转交某些硬件设备继续工作时，它顿时当起了甩手掌柜，任由愚蠢的硬件来完成任务。任何用
    户都可以看出这样的软件不体贴，不负责任，这种软件没有分担责任来帮助用户变得更加高效。</p>

<p>例如，在一个典型的打印操作中，程序开始发送 20 页报告给打印机，同时打开带有取消按 钮的打印过程对话框。如果用户很快意识到自己忘了一个重要的改动，他在打印机刚打出第 1
    页时单击取消按钮，程序立即撤销打印操作。但是用户不知道的是，当打印机开始打印第 i 页 时，计算机已经把 15 页报告交给了打印机缓存。程序取消的是最后 5 页，但是打印机对取消操 作一无所知。它只知道要完成交给了它的 15
    页任务，于是继续打印。同时，程序还自鸣得意地 告诉用户打印己经取消。用户可以清楚地看到程序在说谎。</p>

<p>用户对程序与打印机之间的通信问题没有多少理解。他不关心通信是否是单向，只知道在 打印机输出栏中出现第 1 页纸之前已经决定不打印文档。他单击了 “ 取消 ” 按钮，然而愚蠢的 程序仍然继续打印了 15 页。</p>

<p>想象一下，如果程序可以和打印驱动器通信，打印驱动器也可以和打印机通信，用户的体 验会怎样呢？如果程序足够聪明，打印工作就可以在第 2 页纸浪费之前轻松地取消掉。打印机 当然也有取消功能，只是软件在设计时偷懒没有设计这一功能。</p>

<p>体贴的软件能够帮助你避免犯低级错误</p>

<p>当你要做一些肯定会后悔的事情时，比如在一群陌生人面前大声咆哮你的个人私事，或者 要把一个空信封交给领导的时候，一位乐于助人的同伴会默不作声地把你叫到一旁，委婉地指 出你的错误。</p>

<p>数字产品也应该在类似情况发生时这样帮助你。比如，当你想将信息发送给某个朋友，而 不小心发送给全部朋友时，或者要给部门领导发送电子邮件时，忘了把邮件中提及的季度报告 附进去的时候，数字产品应该像人类伙伴一样及时给予提醒。</p>

<p>然而这种提醒不应该以标准的错误信息对话框的形式阻止动作的发生，这只会在伤口上撒</p>

<blockquote>
    155
</blockquote>
<p align="right" height="0pt" width="0pt">About Face 4 :交互设计精髓</p>

<p>盐。恰当的方式是通过细致的视觉和文字反馈，提醒你正在将信息发送给全部朋友而不是单个 人，或者尽管你在邮件中提到要添加相关附件，却忘了这么做。</p>

<p>在后一种情况中，你的电子邮件应用程序甚至可以毫无模式地标出缺失区域，提醒你添加 附件，同时给你选择是否继续发送无附件的邮件，防止软件误解了你的意图。</p>

<p align="right" height="6pt" width="0pt">产品能够更进一步帮助用户避免令其尴尬的错误，并不因此责备用户，这样产品会快速赢
    得用户的信赖和忠诚。体贴的产品设计是区别一般产品和伟大设计的标志之一，也许是唯一的</p>

<p><span id="filepos0000923206"></span></p>

<p><font size="6">设计聪明的产品</font></p>

<p>除了要体贴，好用的软件和人类一样还应该是聪明的。科幻小说家和未来主义者对智能产 品的描述，使得人们对于交互产品聪明的理解有一些迷惑。一些天真的观察家们认为软件确实 有智能。</p>

<p>但是对这个术语更有用的理解（如果最近 10 年内，你想尝试运输货物的话）是：在条件十 分困难，甚至用户空闲的情况下，这些程序仍然能够努力工作。无论我们梦想的会思考的计算
    机是什么样子，我们其实有更好且更直接的方法可以让计算机更努力工作。本章将讨论一些重 要的方法，帮助软件更努力地工作，更好地为人类服务。</p>

<p><span id="filepos0000924236"></span></p>

<p align="right" height="2em" width="0pt">利用计算机的空闲周期</p>

<p>每个程序中的每个指令都必须经过中央处理器（ CPU) 传递单个文件，因此我们需要为它 优化程序。开发人员通过辛苦工作来保证指令数量的最小化，保证为用户提供良好的表现。然 而我们通常会忘记，只要 CPU
    快速地结束了所有工作，就开始空闲下来，什么也不做，直到用户 执行下一个命令。我们为减少计算机的反应时间投入了大量的努力，却投入了很少或者几乎没有投 入精力，以使计算机在没有响应来自用户任务时做一些前瞻性的工作。软件向 CPU
    下命令，就好 像军队一样，间歇性的命令使其行动或等待。行动的部分非常好，然而等待应该到此为止了。</p>

<p>在当前的计算机系统中，用户需要记住的事情太多，如文件名和文件在文件系统中的精确 位置。如果一个用户想找到季度计划的电子表格，他必须记住文件名或者进行浏览。在这期间， 处理器处于停止状态，浪费了数 10 亿次的循环运转。</p>

<p align="right" height="6pt" width="0pt">当前多数软件也不关注情境。例如，当用户在辛苦地赶制电子表格工期时，程序能为其提
    供的最大帮助也就跟他在空闲时间玩数字游戏差不多。凭良心说，软件再也不能在用户工作时</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>浪费这么多空闲时间了。在日常生活中，我们的计算机应该开始肩负起更多的责任。</p>

<p>在通常情况下，多数用户在不足几秒的时间内能做的事情很少，但这足以让典型的桌面计 算机执行至少 10 亿条指令。无疑，这些周期都是空闲的。处理器除了等待，没有做任何事。反 对利用这些周期的人总是认为： “
    我们不能做出假设，这些假设可能是错误的。”当前计算机的 功能是如此强大，尽管这些说法是对的，但通常这种说法不值一提。简单而言，如果程序的假 设是错的也没关系，它有足够的空闲和能力做出几个假设，而在用户做出最终选择时丢掉其他
    假设结果。</p>

<p>在 Windows 和 Mac OS X 的多线程化、多任务系统及多核多芯片系统中，你可以在后台执 行额外的工作，而不影响用户当前的任务。程序可以启动查找文件，如果用户开始输入，程序
    可以放弃，直到下一次空闲时钟周期。终于用户停下来思考，而程序已经有了足够的时间扫描 整个硬盘，用户甚至不会注意到。这就是 Mac OS X 中 Spotlight 的搜索比 Windows 搜索好很多
    的地方。搜索结果几乎是同时出现的，因为系统利用了很多空闲时间来索引硬盘。</p>

<p>程序每次提供一个模态对话框时，它就进入空闲等待状态。当用户处理这个对话框时，它 什么事都不做，实在不应该出现这种情况。对于对话框来说，找到合适的帮助方法不会很困难。 用户上次是怎么做的？例如程序可以向用户建议以前的选择。</p>

<p>我们需要以全新并更主动的方式来思考软件应该怎样帮助人们实现其目标和任务。</p>

<p><span id="filepos0000928942"></span></p>

<p>聪明的软件有记忆</p>

<p>稍微一想就会明白，如果人们感觉某个交互产品是体贴和聪明的，那么这个产品肯定具有 关于这个人的知识并从其行为学习的能力。早期出现的体贴的产品就证实了这个事实，对一个
    体贴并且很有帮助的软件来说，能够记住与之交互的人的相关信息是非常重要的。</p>

<p>开发人员和设计师通常假设用户的行为是随机的、难以预测的，并认为用户会通过不断的 询问来决定任务的合适过程。然而人类行为肯定不会像一台电子计算机一样被决定，而且也明 显不会是随机的，向用户提出傻问题肯定会让用户感到烦扰。</p>

<p>多数软件是健忘的，每次运行时很少记忆，甚至不记忆任何东西。如果我们的程序足够聪 明，在使用期间能保留一些信息；通常这些信息也只是为了使幵发人员更容易开展工作，而不
    是为了用户。程序自动丢弃一些信息，如使用方式、改变方式、使用场合、处理的数据内容、 用户是谁，程序的不同功能是否用到，或者使用的频率如何等。在这期间，程序用驱动程序名、
    端口分配和减轻程序员压力的其他细节填充初始化文件。从用户的角度看问题，使用相同的功 能设施可以显著提高软件的智能。</p>

<blockquote>
    157<br/>
    <br/>
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>如果你的程序、网站或者设备能够预测用户下一步要做什么，那么它难道不能提供更好的 交互吗？如果你的程序可以预测用户在特定对话框或表单中的选择，难道不可以跳过那个部分
    的界面吗？难道你不认为预测用户会采取什么行动是界面设计卓越的秘密武器吗？</p>

<p>你可以预测用户将要做什么，可以在程序中建立第六感，不可思议地准确预测用户下一步 将要做什么！那些数以 10 亿计浪费掉的处理器周期都会得到充分利用，你所需要做的就是给界 面赋予记忆的功能。</p>

<p>当我们在这种场景下使用记忆这个术语时，指的不是随机存取存储器（ RAM )，而是指在 多次会话中跟踪和反应用户行为的程序工具。如果你的程序简单地记住了用户上次做了什么(或 者怎么做的），它可以凭此来预测用户下次的行为。</p>

<p>如果我们能够赋予产品了解用户行为的能力，记忆并灵活地根据用户之前的行为显示信息 和功能的能力，那么在用户效率和满意方面会有很大的提高。我们都希望有个聪明且自觉的助
    手，具有灵敏的直觉、源源不断的动力和好的判断，以及值得信赖的记忆。一个让使用过程充 满效率的产品就很像一位自觉的助手，记住了所有有帮助的信息和个人偏好，而不用去问。简
    简单单就会有巨大的不同，不同之处在于用户是喜欢还是在忍受你的产品。下次当你发现程序 向用户提问时，设法也让程序向自己提出一个问题。</p>

<p><span id="filepos0000933308"></span></p>

<p>聪明的产品能够预测需求</p>

<p>通过回忆用户上次的行为来预测用户将要做什么，这是基于任务一致性原则 （task coherence) 做出的揣测。我们每天的目标和实现目标的方式（通过任务）通常是相同的。这不
    仅适用于像刷牙和吃早餐这样的任务，而且对于使用文字处理器、电子邮件程序、手机和电子 商务网站这样的任务也适用。</p>

<p>当消费者使用产品时，使用的功能及使用方式和上次很可能极为相似，它甚至可能在同一 个文档中工作，或者至少相同位置的相同类型文档上工作。的确他不会每次都做完全相同的事
    情，但是他很可能有少量的重复模式；因为具有明显的可靠性，所以你可以通过简单的权宜之 计，即记住用户前几次使用的情况来预测他的行为，这样可以让你大幅减少程序必须向用户提 问的次数。</p>

<p>例如，尽管莎莉使用 Excel 的方式和她使用 PowerPoint 或者 Word 的方式大不相同，但她 每次使用 Excel 的方式却可能极为相似。莎莉喜欢使用 12 磅的 Helvetica 字体，这一喜好是个
    可靠的规律，并不需要程序询问她使用哪种字体或将哪种字体设置为默认格式。 12 磅的 Helvetica 字体对于莎莉来说是个可靠选择，每次如此。</p>

<p>158<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>应用程序还要密切关注各种动作。比如，在文字处理器中，你可能经常使用反白文本，在 黑色底板上写白字。为了做到这一点，你选择一些文本并将其字体的颜色改成白色，在没有改
    变选择的情况下，又将背景颜色设置成黑色。如果程序充分注意到这一点，它会发现你要求的 两个格式化步骤中间没有其他选择。在你看来这是有效的单一操作，如果程序能够将这个独特
    的模式重复几次，自动创建这种类型的新风格不是很好吗；或者比这更好，即创建一个新的反 白工具栏控件。</p>

<p>多数主流程序允许用户设置默认值，但这并不能算作一种聪明的行为。即使对超级用户来 说，这种设置也是烦琐的过程，许多用户永远不会理解如何定制他们喜欢的默认值。</p>

<p><span id="filepos0000936953"></span></p>

<p>聪明的产品能够记住细节</p>

<p>确定程序应该记住哪些信息有一个简单的原则，即如果用户愿意操作，它就值得被程序记住。</p>

<p><img align="baseline" alt="" height="71" src="../Images/Image00201.jpg" width="55"/></p>

<p><img align="baseline" alt="" height="40" src="../Images/Image00161.jpg" width="56"/></p>

<p>用户做的每一件事都应该记住。我们的硬盘驱动器中有充足的空间，而程序的记忆功能是 对存储空间很好的投资。我们常常认为程序浪费磁盘空间，因为一个大的应用程序可能要占用 200MB
    的空间。那是程序的通常用法，但是对于大多数的用户数据来说事实并非如此。如果你的 文字处理程序在每次运行时保存 1KB 的执行笔记，它仍然不会占据那么多空间。比如，你每个 工作日使用文字处理器 10 次，每年大约有 250
    个工作日，每年运行程序 2 500 次，净消耗量也仍 然只有 2MB, 这还是对全年的盘点。这个量大概还没有你桌面上的背景图像所占用的空间大。</p>

<p>设计原则</p>

<p align="right" height="6pt" width="0pt">如果用户愿意操作，就值得程序记住。</p>

<p>任何时候，程序出现一个选项，尤其是已经向用户提供了该选项时，程序都应该记住这些 信息。程序可以使用用户以前的设置作为默认值，而不是使用无法更改的常量默认值，这样更
    有可能满足用户所需。程序应该直接做出与用户上次选择相同的决定，而不是向用户询问。如 果错了，可以让用户纠正。无论用户设置的选项是什么，程序都应该记住。这样一直保留这些
    选项，除非用户重新更改。如果用户跳过程序或者关闭其功能，则不应该再向用户提供了；但 在用户乐意接受它们时，仍然能找到它们。</p>

<p>没有记忆功能的程序最讨厌的特点之一就是它们对文件和磁盘的帮助很少。用户需要帮助 的地方也就只有文件和磁盘。像 Word 这样的程序能够记住用户上次查找文件的位置。遗憾的
    是，如果用户总是将其文件放在名为信件的目录下，但是只要用户有一次编辑一个文档暂时存 放在临时目录下，那么之后他的所有书信都会存储在临时目录下，而不是书信目录下。所以程
    序不仅要记住文件最后一次访问的位置，而且必须记住每种类型的文件上次访问的位置。</p>

<blockquote>
    159
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>窗口的位置也应该记住，如果你上次将文档最大化，那么下次它也应该是最大化的。如果 用户将窗口设置为与另一个窗口相邻，那么下次在用户没有给出任何指令时，窗口也应该以相 同的方式设置。现在，微软 Office
    应用程序在这个方面已经很成功。</p>

<p>记住文件位置</p>

<p>所有打开文件的功能应该记住用户访问文件的位置。对于每个特定程序，多数用户只从极 少的几个目录访问文件。程序应该记住这些源文件夹，并在打开的文件对话框中提供这些文件 夹。这样，用户再也不用每次都浏览文件夹目录进入特定文件夹了。</p>

<p>推断信息</p>

<p>软件不应该只是简单地记住一些明显的事实，还应该从这些事实中推论出有用的信息。例 如，如果程序记住了文件每次打开时修改的字节数量，那么它能够帮助用户检查修改操作的合 理性。假设文件修改字节数量的历史数据为 126 、 94 、 43 、
    74 、 81 、 70 、 110 和 92 。如果某次 用户调用这个文件，修改了 100 个字节，可能不会有影响。但若修改字节的数量突然激增到 5000 ( 可能因此永久性地删除了一页内容 )
    ，程序可以认为出现了某种错误。虽然用户有可能不小心 做了令他难过的事，但这种可能性很低，所以不应该用一个确认对话框打扰他。但是程序有理 由在修改 5000 字节之前保留一个重要的副本以防万一。程序可能只需要在用户再次打开这个文
    件之前保留这一副本，因为用户一眼就会发现错误，然后他会取消之前的操作。</p>

<p>取消多会话</p>

<p>在用户关闭文档或程序时，多数程序会放弃撤销堆栈，这是非常短视的行为。相反，程序 可以将撤销堆栈写入文件。当用户重新打开文件时，程序可以加载用户上次运行程序时的取消 堆栈，即使那是一个星期之前的事。</p>

<p>录入过去的数据</p>

<p>一个有良好记忆功能的程序可以降低用户犯错的次数，原因很简单，用户必须输入的信息 大量减少，更多的信息可以通过程序的记忆直接获得。许多浏览器都具备这一功能，尽管智能
    手机或桌面程序很少有这个功能。例如，在一个货品计价程序中，如果软件从过去的记忆中获 取曰期、部门编号和其他标准字段，负责开发票的员工在这些字段上犯输入错误的机会就会变 得很少。</p>

<p>如果程序记住了用户输入的信息，并且将这些信息用于将来的合理性检查，程序就可以拒 绝输入的错误数据。现在的网络浏览器，比如 IE 或者火狐提供了一种机制，即命名的数据输入
    域记住了以前输入的数据，允许用户从组合框中挑选一个值。对于安全意识强的用户，可以关 闭这种特性。但对于其他人来说，它既节省时间，又能防止错误发生。</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>程序文件的外部程序活动</p>

<p>应用程序在调用之前可以启动一个很小的线程，这个小线程密切关注它所处理的文件。它 可以追踪文件移动的位置，谁对它进行了读写，这些信息在用户再次运行该程序时也许有一定
    的帮助。当其试图打开一个特殊文件时，程序可以帮助查找，即使文件已经移除。程序可以告 诉用户在其文件上执行了什么功能，如是否打印或者传真给某人。当然，用户可能并不需要这
    种信息，但这点时间对于计算机来说不算什么，毕竟对于所浪费的空闲周期来说，这不过是九 牛一毛。</p>

<p><span id="filepos0000946613"></span></p>

<p>让聪明的产品发挥聪明</p>

<p>如果设计人员能够认识到任务一致性在软件设计过程中的作用，那将不同凡响。设计师会 发现他们的思路会呈现全新的面貌。通常跳出的对话框不假思索地不见了，取而代之的是设计
    师更多细致问题的提出和更具研究性过程的出现。程序应该记住多少？记住哪些方面？除了上 次的设置，是否还需要记住其他设置？模式有什么改变？设计师开始想象以下情况：用户连续 50
    次接受同样的日期格式，然后人工输入一次不同的日期格式。等下次用户输入一个日期，程 序应该使用哪种格式呢？ 50 次相同的格式，还是最近一次使用的格式？ 一种新格式使用多少次
    后会成为默认格式？即使存在疑问，程序仍然不该向用户提问。它必须发挥自己的主动性做出 选择。如果错了，用户可以自行更改程序选择。</p>

<p>下面的内容将对人们做出选择的一些特征模式进行阐释，这有助于我们解决一些与任务一 致性有关的更复杂的问题。</p>

<p>缩小决策数量</p>

<p>人们倾向于将决策选择降低到最小的有限数量。甚至当你每次做的事并不完全相同时，也 常常会从一个重复的较小选项集合中选择自己的行为。人们在无意中缩小决策集合，但软件可 以将其记录下来，并遵照它行事。</p>

<p>例如，仅仅因为你昨天在西夫韦购物，并不意味着你只在那里购物。但是，当下次需要曰 常用品时，你可能又会选择西夫韦。同样，即使你喜欢的中国餐馆菜谱有 250 道菜，你也经常
    会从自己偏爱的几道菜中做出选择。当人们开车上班或回家时，也经常是依据交通情况从少量 几条熟悉的路径中选择。当然，计算机可以毫不费力地记住这四五件事。</p>

<p>尽管简单记住最后一次的动作比不记任何事要好得多，但如果决策集合仅由两三个元素组 成，它仍可能带来特殊的麻烦。比如你交替地从一个文件夹中浏览文件，而在另一个文件中保
    存文件。程序每次自动检索到上一次打开的文件夹，那它肯定无法提供用户想要的，唯一的办</p>

<blockquote>
    161<br/>
    <br/>
</blockquote>
<p>About Face 4 :交互设计精髓</p>

<p>法就是记住更多选择。</p>

<p>缩小决策集合使我们想到，程序必须记住的信息应该是用户经常使用的一组信息。和只有 一个正确答案的情况不同，好几个选项都是正确的，程序应该寻找更加微妙的线索来在小的集
    合中确定哪一个才是正确的。例如，如果你用支票程序付账单，程序很快就会知道只有两三个 账户是经常使用的。但是它怎样才能知道对于一个特定的账单，哪个账户是最合适的呢？如果
    程序记得付款人和每笔账目的数量，就能比较容易做出选择。每次你付的租金数量是完全相同 的。支付汽车贷款也是这样，支付给电气公司的每笔账目可能会有变动，变动大概在上次账目 的 10% 〜 20%
    之间。所有这些信息可以帮助程序了解具体情况并利用这些情况帮助用户。</p>

<p>偏好阈值</p>

<p>人们所做的决策一般分为两大类，即重要的和不重要的。任何特定的动作都包含了上百次 的决策，但是其中只有很少是重要的，其余的都不重要。软件界面可以用偏好阈值来简化用户 任务。</p>

<p>在决定购买汽车之后你不会在意为其筹钱，只要物有所值。决定购买日用品，选择哪个结 账口付款不重要。在决定到迪斯尼乐园的马特洪峰驰骋时，你不会在乎乘坐的是哪个滑车。</p>

<p>偏好阈值证明，不断地向用户询问程序决策细节是不必要的，从而可以在用户界面设计中 给我们指导。用户请求打印之后，不必问他需要多少份，也不必问图像是横向还是纵向。我们 可以将这些设置假定为第 1
    次使用的情形，并且为后继的调用记住这些设置。如果用户希望更 改设置，可以启用打印机选项对话框进行修改。</p>

<p>使用偏好阈值，我们可以轻易地跟踪哪些程序功能是用户喜欢调整的，哪些是用户一旦设 置好后就不会再改变的。知道这些后，程序可以在用户想控制的地方提供选择，而不必在用户 不感兴趣时打扰他。</p>

<p>多数情况下，多数是对的</p>

<p>任务一致性能够合理地预见用户的下一步行为，但也不是绝对的。如果我们的程序依靠该 原则，自然会遇见不确定性。如果我们能够以 80% 的准确率预见用户行为，则还有 20 %的情况 是错的。可能有人认为应令用户选择，但用户可能在 80%
    的情况下被不必要的对话框打扰。程 序应径直做其认为最恰当的事，然后允许用户覆盖撤销，而不是让用户选择。如果撤销工具很 容易使用、理解，用户就不会受到无谓的干扰。毕竟 10 次中只有 2 次需要撤销，而省去了 8
    次多余的对话框，是很合算的。</p>

<p>162<br/>
    <br/></p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p><span id="filepos0000954683"></span></p>

<p><font size="6">设计社交软件</font></p>

<p>利用现代软件创建的大部分内容并非只为其作者服务 ( 任务单、提醒和个人日志可能除外）， 多数内容要呈现出来：演示需要受众观看，文档需要浏览者阅读，图像需要观众观看，状态更
    新需要用户喜欢；与内容需要回顾一样，程序也需要在某一业务过程的下个步骤中使用。即便 是为机器设计的一行行程序编码，也都是遵循结构化格式并使用其他开发人员能够读懂的语言 编写的。</p>

<p>通常，缺乏联系性的软件会将这部分内容通过文档或者为任务而特别打造的软件交由用户 完成，例如电子邮件代理。但随着软件越来越复杂以及对用户目标与日俱增的尊重，这种分享
    和协作特性也随之进入设计范畴。软件开发逐渐变成开放的办公室，在这里合作者甚至顾客都 近在咫尺；而不像过去，设计人员瞬间消失不见，像钻进隐秘的小屋搞创造，随后又忽然出现</p>

<p>在你面前。</p>

<p>截至目前，本章已经讨论了好的软件应该如何体贴用户。当我们同其他用户通过软件媒介 机制交流时，原则是一样的；但除此之外，还要考虑产品的社交规范和其他用户的期望。</p>

<p><u>社交软件要知道社交规范和市场规范的区别</u></p>

<p>每一个群体都有其成员必须遵循的规则，而最大的两种规则就是社交规范 (social norms )和 市场规范（ marketnorms )。</p>

<p>社交规范存在于朋友和家庭成员之中，并互相遵守。如困难时伸出援手，表达感恩。</p>

<p>市场规范则是属于生意人需要遵守的潜规则，包括物美价廉、守信用等。</p>

<p>这两个概念之间有很明显的不同。在社交背景中错误使用市场规范会被看作极端粗鲁的行 为。想象一下，当你在朋友家里享受完一顿美餐后，将钱甩在桌上就走，有多不礼貌。同样，
    在市场环境中误用社交规范会让你陷入违法的境地。假设你在餐馆握着服务员的手说谢谢你， 饭菜太美味了！ ” 然后不付钱就离开餐馆，餐馆老板就可以直接告你吃霸王餐。</p>

<p>想要避免粗鲁或违法，软件必须了解用户在哪种环境中使用产品。通常明显的做法是釆用 限定域，但更多情况下所包含的系统可能会挑战跨过这些限定域。你可以通过 Linkedln 与朋友 联系。 Facebook
    上有好几页的公司用户。组织内部使用的聊天软件按照半社交规则设计，因为 该组织成员在生意上要相互帮助。而聊天软件才是交易双方真正实现会面的地方。</p>

<p>遵守市场规范的软件应该保证交易各方公平，扮演 “ 媒人 ” 和让人信赖的第三方托管角色。</p>

<blockquote>
    163
</blockquote>
<p>遵守社交规则的软件应该帮助用户以互惠互利的方式坚持亚文化规则和等级观念。</p>

<p>社交软件帮助用户展现最好的一面</p>

<p>对设计者来说，在社交界面上展现用户就是个很大的挑战。他们要思考如何让这一展现独 一无二、可识别、可描述且有用。以下策略可以帮助用户在网络上代表自己。</p>

<p>用户身份</p>

<p>使用名字代表用户身份的确具有吸引力，但名字并非永远独一无二，也不一定合适。</p>

<p>像谷歌文档将彩色的动物形象作为图标一样，半随机选择自己的图标也很具诱惑力（作者 在书写的同时，还选择了一个可爱的紫红色熊猫图标）。设计者使用半随机视觉图像方框来保证
    用户图标风格与软件的外观和感觉统一，但这增添了认知方面的负担，因为用户必须记住图标 背后的人是谁。为了把这种负担降至最低，头像另一端的用户可以选择无所属权的图标-颜色组 合或者上传自己的图片作为最适合自己的视觉头像。</p>

<p>上传图片有可能选择不恰当内容，但在选择加入网络和可信赖（非匿名）的社交软件中， 社会压力迫使我们对这些图片进行检查。无论如何，全名提示框可以快速提醒用户每个图标代 表谁，以及用户是否需要它。</p>

<p>动态 <font size="2">VS</font> .静态用户形象</p>

<p>用户形象是用户为自己创建在线形象的传统方式，但并非所有用户有时间或者有意愿填写 一堆的静态信息来描述自己。然而，我们可以对用户在网络的社会贡献进行动态收集，并简要
    展现出来：收听的音乐、志同道合的朋友、添加或喜欢的更新内容、提及的书籍或电影、分享 或展示的链接等。 Facebook 的时间轴就是展现这些信息的一个例子。在社交网络中，行动胜过
    自我描述，排名靠前的概述和最受欢迎的贡献是对静态的个人简历的很大补充，甚至可以说是 替代性选择。</p>

<p>对于用户形象的部分任意内容，用户应该完全掌握其浏览权限，能够组织与整理，以使其 看起来适合自己的个性；但对于不怎么讲究的用户来说，默认设定也很不错。</p>

<p><span id="filepos0000962584"></span></p>

<p>允许简单协作</p>

<p>协作是增强软件社交性的普遍原因之一。用户可能期望另一种观点、另一双手或者同事的 支持。以协作为中心的社交软件应能将这一功能深深植入界面当中。</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>比如，微软 Word 让用户对文档添加评论，其他人可以对此评论再添加新的评论。这种做 法很时尚，但遗憾的是，这些评论最终可能会变得杂乱无章，与源评论脱节。</p>

<p>谷歌文档做得要好一些。它允许协作者直接回复，几乎并行，允许任何协作者点击按钮“解 决 ” 问题，并提供一片区域重新打开原有的、已解决的问题。这样更适合人们讨论并解决问题。
    设计者应该保证协助工具明显、可用，且能满足人物模型的协作需求和交流行为。</p>

<p><span id="filepos0000964052"></span></p>

<p>知进退</p>

<p>诸如谷歌文档这类只有外部社交功能的软件中，社交功能不应该超越或干扰主要任务。当 然社交软件必须表现其他用户的互动，但应细致，应能在充分尊重用户的前提上闪动、哔声提
    醒我们有用户进入文档，这是一种万全之策。其实，用户应该有礼貌但坚决地拒绝干扰，暂时 中止任何外部社交，从而集中全力地完成某项任务。</p>

<p><span id="filepos0000964669"></span></p>

<p>助于增长网络健康</p>

<p>随着新成员加入、联系、交互、驻留或离开，网络人群也一直在增长、变化。社交软件应 该提供途径和方法，以便让新成员发现网络，然后加入、露面、学习规则、开始参与，并在成
    员违反亚文化规范的时候稍稍提醒。中级成员应该有方法打造自身优势、培养新成员以及向高 级成员寻求帮助。高级成员应能有效管理网络。所有成员都需要一种方法以暂时或者妥善地退
    出。有点毛骨悚然的是，网络必须优雅地处理成员去逝后的事宜。</p>

<p>根据社交规则，特别头疼的社交问题是在用户不同意联系的情况下要处理另一用户的联系 请求。拒者会给别人留下冷淡、冷漠的印象。当邮件收发室的一位新实习生希望通过 Linkedln
    联系一家大公司的首席执行官而后者不想联系前者，但又不想让这位员工觉得自己不受重视时， 为了顾及脸面，不情愿的用户需要将责任转移到明确的社区规则，或充当守门人角色的另一用 户，抑或是系统限制上。</p>

<p>社交产品尊重社交圈的复杂性</p>

<p>设计师要记住网络社会心理学底限。灵长类动物学研究发现，灵长类动物的大脑皮层的面 积与其部落的平均大小相关。小于一个限值的部落会缺乏安全感，而大于这个限值的部落则会 不稳定。</p>

<p align="right" height="6pt" width="0pt">为了纪念提出这一理论的人类学家罗宾 • 邓巴 （Robin Dunbar), 人们把这一限值叫作“邓巴 值 ”
    。而一个明显的后续问题就是，人的邓巴值是多少？根据我们大脑皮层的面积，这一数值大</p>

<p align="right" height="10pt" width="0pt">165</p>

<p>About Face 4 :交巨设计精髓</p>

<p>概为 150, 这是社会关系中确保每个成员充分发展的普遍限值。如果软件允许网络大于这一数值 , 若无明确的规则、行为机制，以及管理相应复杂关系的一组工具，网络将会陷入不稳定的风险。</p>

<p>譬如谷歌文档这类稍具社交性的软件允许他人协助处理个人文档，并遵循严格的邀请及严 格选择的规则；用户可能获得几个层面的权限，而决定权属于最初文档的主人。这类软件将复 杂的决策问题留给了用户。</p>

<p>其他软件，则在网络参与方面有更为慎重的规则。比如 DmpBox 是一种文档分享软件，允 许用户对分享文档的对象进行定义。用户可以邀请其他用户，甚至允许机构以外的人进入个人 文件夹或文档。</p>

<p>明确的社交软件可以包含大量不同圈子的人群。拥有大约 10 亿用户的 Facebook ,能够搜 索到与用户相关的同事、核心家庭成员、大家庭、朋友、对手、邻居、以前的邻居、校友、前
    校友、熟人、兴趣相投的圈子、雇主、潜在雇主、雇员、客户、潜在客户、爱人、情人和对手 等人群。每个次群体的规则和规范对用户来说至关重要，因为这些规则和规范可用于对这些群 体进行区分。</p>

<p>比如，你的大学同学看到你深夜豪饮的照片可能会兴奋，但并非所有家人都乐意看到这些 照片，至于你的老板或客户几乎肯定会不高兴。这就需要一种管理机制，确定哪些内容适合哪 个朋友圈；然而遗憾的是，很难找到这种机制，即便有也很难使用。比如
    Facebook 偶尔也会发 生让用户难堪的事情。这种情况下，及时更改和撤销操作的功能就至关重要。 Facebook 社交网 站的对手，谷歌则为用户提供了更为清晰的机制，帮助用户了解和管理社交圈，动画和现代感
    十足的布局为网站增添了很多乐趣。</p>

<p>其他定位更明确的社区可能会提供会员的准入制，这可以根据角色和资历来定。维基百科 拥有大量的读者，其中只有少部分人能够编写网页，更少的人拥有颁发许可的管理权限。</p>

<p>软件越大越复杂，就越要在设计过程中关注社交网络的复杂性。</p>

<p>社交产品尊重其他用户的隐私</p>

<p>像 Facebook 和谷歌社交网站这种靠广告驱动的社交媒介，由于其强烈的金钱刺激，很容易 出现不尊重用户隐私的现象。对用户了解和分享得越多，广告的针对性越强，网站向广告商收 取的费用也就越高。</p>

<p>而另一方面，用户希望感受到自己的隐私被尊重，并且能够主动拒绝接受一项跟自己不相 干的服务。尤其是 Facebook 经常会出现问题，比如更改政策以显示更多的用户信息，而事先不
    会向用户解释为何做出这种改变，并且将这些改变设置得更加难以发现、理解和使用。因此当</p>

<p align="right" height="0pt" width="0pt">第 8 章数字产品的礼仪</p>

<p>用户评论一张冒险的图片时，会突然惊讶地发现贝西阿姨正在因此而指责他。 Facebook 这些反 复、不体贴的错误会使用户越来越背离它。</p>

<p>考虑周全的社交软件会把额外的分享变成一件悉心解释、选择性加入的事情。而根据商业 规范，这有可能引发知识产权方面的问题，所以要倍加小心。</p>

<p align="right" height="2em" width="0pt">社交软件要恰当处理反社交行为</p>

<p>滋事者指的是反抗社交体系的行为，包括干涉交易、谈话中制造噪音甚至破坏正常工作。 亚马孙就不得不处理很多滋事者引发的问题，他们总是喜欢对在售的商品妄加评论。在一些可
    以简单、匿名方式申请账户的大型网络系统中，滋事者对自己的言行更不负责，这会是一个大 问题。社交软件为用户提供了工具，以阻止滋事者破坏交易、将滋事者排除在各个圈子外并将
    其行为报告给社区管理者。这些工具的意义在于帮助管理员把真正的反社交用户和迫切想融入 圈子又不受欢迎的用户区分开来。</p>

<p align="right" height="29em" width="0pt">167</p>
</body>
</html>
